msvcrt:scanf float conversion behavior

[Erich E. Hoover]

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>
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, 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
scanf.

> 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
> "1.5475148155234508e-252"

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
for 1.5475148155234508e-252.

> The test that produces the biggest error for strtod function is:
> 4.0621786324484882e-053

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
scanf).

> There's
> 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
that big.

> ...
> 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.

Best,
Erich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20191227/7a349435/attachment.htm>