On 25.06.2017 20:39, Liu Hao wrote: >>>> I've checked and both _POSIX_C_SOURCE=1 and __USE_MINGW_ANSI_STDIO=1 >>>> don't affect this define. >>> It should, at least the latter one should show effect. Of course you >>> need to define it before including inttypes.h >> Very simple test case: >> >> a.c ====== >> #include <inttypes.h> >> PRId64 >> ========== >> >> $ gcc -D_POSIX_C_SOURCE=1 -D__USE_MINGW_ANSI_STDIO=1 -E a.c >> [skipped a lot] >> # 1 "C:/msys64/mingw64/x86_64-w64-mingw32/include/_mingw_print_pop.h" 1 3 >> # 300 "C:/msys64/mingw64/x86_64-w64-mingw32/include/inttypes.h" 2 3 >> # 2 "a.c" 2 >> "I64d" >> $ >> > Confirmed. > > This is because the following `#if` on line 8 in <_mingw_print_pop.h> > prevents the preprocessor from restoring those macros if neither > <stdio.h> or <wchar.h> is included before <inttypes.h>: Problem is, here could be files which don't need nor <stdio.h> neither <wchar.t>, but need formatting macros. For example, if custom logging subsystem used (it is my case) or it is file defining a lot of messages but no any code at all. I think, it is minor bug in mingw64. Should I file it?
-- // Black Lion AKA Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
