wchar_t printf() format warning

[Eric Blake]

On 03/19/2015 10:14 AM, Craig Howland wrote:
> 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.

I _want_ the warning for potentially inconsistent types, even if they
are not a problem for the ABI of my current compilation, so that I can
fix my code to be correct when porting to another platform where the ABI
difference DOES matter.  In fact, I wish gcc could be even smarter, and
warn about '"%ld", (size_t)' even on platforms where size_t is
implemented the same size as long (at the moment, it takes either
intentional compilation on a different platform, or the use of clang
and/or Coverity to catch those sorts of mismatches where gcc isn't
warning on more mainstream platforms).

But I can also see your point about a mode of operation where gcc
doesn't warn when the ABI is not violated, even though the types are not
consistent.  gcc already has -Wformat=2 vs. -Wformat=1, so making the
warning level tunable by whether you care about mismatch should
certainly be feasible in that framework (even if by adding -Wformat=3).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 604 bytes
Desc: OpenPGP digital signature
URL: <http://sourceware.org/pipermail/newlib/attachments/20150319/8d855b06/attachment.sig>