Blue Swirl <blauwir...@gmail.com> writes: > On 5/17/10, Markus Armbruster <arm...@redhat.com> wrote: >> Blue Swirl <blauwir...@gmail.com> writes: >> >> > On 5/16/10, Stefan Weil <w...@mail.berlios.de> wrote: >> >> Am 15.05.2010 22:49, schrieb Blue Swirl: >> >> >> >> >> >> > Hi, >> >> > >> >> > With this mingw32 compiler: >> >> > >> >> > $ i586-mingw32msvc-gcc -v >> >> > Using built-in specs. >> >> > Target: i586-mingw32msvc >> >> > Configured with: >> >> [...] >> >> >> > build will not succeed because formats %zd, %zu, %hh, %lld, %llx and >> >> > %llu are not known by the compiler. >> >> > >> >> > Any %ll* use is clearly a bug, we have PRI*64 macros just for this >> >> purpose. >> >> > >> >> > For %hh and %z there may be better ways than these patches. >> >> > >> >> > With the patches I can build working Win32 binaries and there are no >> >> warnings. >> >> [...] >> >> >> It's a compiler bug that the compiler does not know these format strings. >> >> The code works nevertheless (at least with mingw libraries which are >> >> not too old) because the format strings are interpreted by the C runtime >> >> library. >> >> >> >> Is it worth changing a lot of files when we can expect a newer mingw >> >> compiler version which works correctly for standard format strings? >> > >> > When and if that version becomes popular, PRIz* and the %hh hack could >> > be removed or a compiler check could be added. But I don't think it's >> > worth it, the macros are easy to use. >> >> >> They're also ugly as sin. > > Avi's signature tells the reason, the macros are products of standards > committees.
Committees have much ugliness to answer for, but they're not to blame for ugly printing of size_t, signed char, unsigned char, long long and unsigned long long. In fact, the committee came up with a non-ugly solution for them: conversion specification length modifiers z, hh, ll. > But on second thought, perhaps it's not OK standard-wise to invent > PRIz* macros, at least they should be prefixed with Q to avoid > conflict. Correct. > That probably does not improve the beauty of the macros. ;-) And correct again. All this ugliness just to silence a single compiler's broken warnings? I'd switch off the warning and be done with it. [...]
