wchar_t printf() format warning

[Craig Howland]

On 03/19/2015 12:12 PM, Eric Blake wrote:
> On 03/19/2015 10:05 AM, Joel Sherrill wrote:
>>
>> On 3/19/2015 10:51 AM, Eric Blake wrote:
>>> On 03/19/2015 09:46 AM, Jonathan Roelofs wrote:
>>>
>>>> That's a platform decision, not a gcc decision. AFAIK, there is no
>>>> language requirement that wint_t and wchar_t be the same type.
>>> In fact, on cygwin, wchar_t is 16-bit, but wint_t is 32-bit, because
>>> there is no free 16-bit value that can hold WEOF.  On the other hand, on
>>> cygwin, passing wchar_t through va_arg promotes to 32-bit, so it happens
>>> to promote to wint_t and programmers can get away without the cast -
>>> whereas your platform was a question of wchar_t (32-bit int) not
>>> promoting to wint_t (32-bit long), making the cast necessary unless you
>>> can fix gcc to not use inconsistent 32-bit types.
>>>
>> Eric.. you've hacked on gcc a long time. Is this worth the trouble with gcc?
> Sadly, while I have gcc commit rights, it was more for work with Java
> than for C (not to mention years ago), so I have no idea how easy or
> hard it would be to change builtin types to be saner.
>
>> It involves a fair number of target architectures and target OSes. Seems
>> of questionable value. What do you think?
> Worth filing a bug against gcc, to at least gauge response from those
> more likely to know how to make the change.  But I think gcc sets
> builtin types according to how the platform requested it, so it probably
> is an issue with the platform configuration files rather than trying to
> teach gcc to not warn when mismatching wchar_t vs. wint_t even though
> ABI-wise they are the same width across va_args.
>
An alternate thought to fixing gcc to not use inconsistent types would
be to get them to not give spurious warnings for printf stuff.  If an
implementation uses the same encodings for long and int, then warning
about having an l modifier (for example) or not is useless on that
particular platform.  Both are passed the same to the function, both end
up the same.  gcc is erratic about whether it warns or not for these
conditions.  While two approaches are possible:  always warn, even if on
a platform for which there is no real difference, or warn only for a
real difference.  I suggest the latter is best, with maybe an option to
get the latter in case there were people who thought strongly about the
former approach.