msvcrt:scanf float conversion behavior
Erich E. Hoover
erich.e.hoover at gmail.com
Fri Dec 27 11:13:39 CST 2019
On Fri, Dec 27, 2019 at 4:48 AM Piotr Caban <piotr.caban at gmail.com> wrote:
> On 12/27/19 4:41 AM, Erich E. Hoover wrote:
> > On Thu, Dec 26, 2019 at 7:05 AM Piotr Caban <piotr.caban at gmail.com>
> >> ...
> >> 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, my approach was to try and get something that can cope with the
53-bit "long double" problem on x86-64 until after code freeze. AJ wasn't
particularly thrilled with adjusting the x87 FPU settings as a workaround.
> The 1.1e-30 tests is an example of a test that stopped working in strtod
> with your patches.
Since this test wasn't in strtod I didn't catch it until trying to fix
> While working on new implementation of strtod I was
> running Chromium string conversion tests (it's a 100k semi random
> doubles conversion test). Here are some results:
I'd be curious to see what this looks like with my new approach, once I
understand why you are getting different test results from me.
> ucrtbase scanf tests:
> - Windows: 0 failures
> - Current 32-bit Wine: 36 failures, biggest error: 1 ulp
> - Current 32-bit Wine with the patch you have attached: 49779
> failures, the exponent is sometimes off by 1, e.g. on
Just to confirm, you're running the current tests for
dlls/ucrtbase/tests/scanf.c on 32-bit x86? The reason that I ask is that
I'm getting 0 failures for that (both with and without the patch) and 0 ulp
> The test that produces the biggest error for strtod function is:
I don't see this test, so I popped it in really quick and I'm getting 1 ulp
with the patch (4 without).
> I'm afraid that your patches will possibly cause tons of regressions and
> I'm not sure yet how to proceed with it during the code-freeze.
I think we need to figure out why we're getting different results on
32-bit. I've been doing most of my testing on 64-bit (since that's what
broke horribly with the _control87 update), but the version I attached
should pass all the current tests on both (whether applied to strtod or
> a quite simple algorithm that should have similar results as msvcrt (I
> will need to implement it in order to know) that can possibly go into
> Wine during code-freeze. On the other hand it will need to be rewritten
> after the code-freeze so I'm not a fun of it. The proper algorithm I was
> working on will definitely exceed 1k lines of code.
Yikes, I figured a properly compliant implementation would be big - but not
> I was thinking about having a common helper that will be used both in
> strtod and scanf. Proper string to double conversion is complicated and
> I don't think it should be mixed with scanf implementation.
Makes sense to me.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wine-devel