This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: wchar_t printf() format warning




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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]