msvcrt:scanf float conversion behavior

Greg codedonewell at gmail.com
Thu Dec 26 22:37:54 CST 2019


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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20191227/de771510/attachment.htm>


More information about the wine-devel mailing list