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