wchar_t printf() format warning
Thu Mar 19 16:14:00 GMT 2015
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.
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 604 bytes
Desc: OpenPGP digital signature
More information about the Newlib