On Thu, 2019-12-26 at 20:41 -0700, Erich E. Hoover wrote:
On Thu, Dec 26, 2019 at 7:05 AM Piotr Caban piotr.caban@gmail.com wrote:
...I was working on different strtod implementation (ucrtbase (as well asglibc) uses sub 0.5 ulp precision algorithm). It's not ready yet. Alsoit's not something that can be added during code-freeze.
Yeah, I was struggling to get something that passes this scanf test(without breaking the more numerous strtod tests):===ret = vsscanf_wrapper(tests[i], "1.1e-30", "%lf", &double_res);ok(ret == 1, "sscanf returned %d for flags %#x\n", ret, tests[i]);ok(double_res == 1.1e-30, "got wrong double %.16e for flags %#x\n",double_res, tests[i]);===I finally came up with the attached the other day, which seems to dothe trick*. If you think AJ might be okay with it then would onlyleave webservices/reader.c:str_to_double with "long double" usage,which I now have a patch for implementing with scanf.
I was not working on scanf changes. It definitely makes sense to notduplicate the code.
I've been poking at this a little bit and it looks like scanf supportseverything that strtod and wcstod need. There are a couple thingsthat our scanf implementation doesn't support yet (inf/nan,Fortran-style exponent notation, and hex notation for floats), butonce those are in place we should be good to go. So, it may makesense to centralize everything in scanf (rather than the other wayaround) so that there isn't any duplication for wide charactersupport. Best,Erich
- Also works well enough that the new compare_double should not
benecessary, unless you've come up with some more test cases ;)
FYI, The existing NaN behaviour for the scanf family is leading to issues with a game. My report is here: https://bugs.winehq.org/show_bug.cgi?id=48323 Returning NaN may not help that issue, but at least might be a better to deal with than just not parsing.
Regards,
Greg