Re: [Qemu-devel] [PATCH 0/3] mingw32 compile fixes

[Markus Armbruster]

Blue Swirl <address@hidden> writes:

> On 5/17/10, Markus Armbruster <address@hidden> wrote:
>> Blue Swirl <address@hidden> writes:
>>
>>  > On 5/16/10, Stefan Weil <address@hidden> 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.

[...]