msvcrt:scanf float conversion behavior

[Erich E. Hoover]

On Thu, Dec 26, 2019 at 7:05 AM Piotr Caban <piotr.caban at gmail.com> wrote:
> ...
> I was working on different strtod implementation (ucrtbase (as well as
> glibc) uses sub 0.5 ulp precision algorithm). It's not ready yet. Also
> it'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 do
the trick*.  If you think AJ might be okay with it then would only
leave 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 not
> duplicate the code.

I've been poking at this a little bit and it looks like scanf supports
everything that strtod and wcstod need.  There are a couple things
that our scanf implementation doesn't support yet (inf/nan,
Fortran-style exponent notation, and hex notation for floats), but
once those are in place we should be good to go.  So, it may make
sense to centralize everything in scanf (rather than the other way
around) so that there isn't any duplication for wide character
support.

Best,
Erich

* Also works well enough that the new compare_double should not be
necessary, unless you've come up with some more test cases ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scanf.diff
Type: text/x-patch
Size: 8094 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20191226/1456483f/attachment.bin>