GMP-6.1.2 [mingw32]: t-scanf.exe fails
keithmarshall at users.sourceforge.net
Sun May 28 12:02:25 UTC 2017
-----BEGIN PGP SIGNED MESSAGE-----
On 28/05/17 10:46, Marc Glisse wrote:
> On Sat, 27 May 2017, Keith Marshall wrote:
>> make: Entering directory `/home/keith/src/mingw/gcc-build/gmp-6.1.2-shared/tests/misc'
>> PASS: t-printf.exe
>> FAIL: t-scanf.exe
>> PASS: t-locale.exe
> Looks related to
Yes, it does appear to be the same, or a very similar issue.
Anyway, I can now confirm it as a bug in wine's sscanf() implementation;
relocating my entire source and build trees to a WinXP VM, deleting the
t-*.log files throughout, and then re-running "make check", as a native
platform test, reports no failures whatsoever ... 100% pass rate.
I am astonished that the use of "-D__USE_MINGW_ANSI_STDIO", as noted in
the previous thread, has any effect whatsoever. See, I am the author of
the underlying code for that feature, and I can state, *categorically*,
that it affects only the behaviour of printf(), and its siblings; it
has no effect at all, on the behaviour of scanf() and its siblings. I
would also point out that, as a "__USE_*" feature test, users should
*not* define "__USE_MINGW_ANSI_STDIO" themselves; the correct way to
enable it is to enable any of the "__STRICT_ANSI__" standards options,
or to stipulate "_GNU_SOURCE", "_POSIX_C_SOURCE", or "_XOPEN_SOURCE"
feature dependencies, (the latter two with an associated version
stipulation), any of which will cause the MinGW runtime headers to
enable "__USE_MINGW_ANSI_STDIO" implicitly. You may get away with an
explicit definition today, but I will offer no guarantee that a future
MinGW Runtime release will not override any such definition, just as
GNU's glibc headers do for their "__USE_*" feature tests.
Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the gmp-bugs