diff options
| -rwxr-xr-x | indra/test/llsd_new_tut.cpp | 14 |
1 files changed, 12 insertions, 2 deletions
diff --git a/indra/test/llsd_new_tut.cpp b/indra/test/llsd_new_tut.cpp index e1de1bbd34..81db191ca6 100755 --- a/indra/test/llsd_new_tut.cpp +++ b/indra/test/llsd_new_tut.cpp @@ -277,8 +277,18 @@ namespace tut v = 0.5; checkConversions("point5", v, true, 0, 0.5, "0.5"); v = 0.9; checkConversions("point9", v, true, 0, 0.9, "0.9"); v = -3.9; checkConversions("neg3dot9", v, true, -3, -3.9, "-3.9"); - v = sqrt(-1.0); checkConversions("NaN", v, false, 0, sqrt(-1.0), "nan"); - + // Get rid of NaN test. First, some libraries don't reliably return + // NaN for sqrt(-1.0) -- meaning that I don't even know how to + // portably, reliably produce a NaN value. Second, we observe failures + // on different platforms in the asString() test. But LLSD's + // ImplReal::asString() does not itself recognize NaN! It merely + // passes the value through to llformat(), which passes it through to + // the library vsnprintf(). That is, even when we do produce NaN, + // we're not testing any LLSD code: we're testing the local library's + // vsnprintf() function, which (empirically) produces idiosyncratic + // results. This is just not a good test case. +// v = sqrt(-1.0); checkConversions("NaN", v, false, 0, sqrt(-1.0), "nan"); + v = ""; checkConversions("empty", v, false, 0, 0.0, ""); v = "0"; checkConversions("digit0", v, true, 0, 0.0, "0"); v = "10"; checkConversions("digit10", v, true, 10, 10.0, "10"); |