The problem is e.g. code calling getwchar and not checking for WEOF.
0xffffffffu does not fit in a 32-bit signed variable unless your code is
confusing signed and unsigned freely. And even if you consider it OK to
check after conversion to wchar_t rather than before, the lack of a wint_t
variable for the result seems likely to accompany a missing check.
Calling printf("%lc", x) with a wchar_t argument hardly suggests
anything about where the argument originated or what checking it
may have been subjected to. Issuing a warning for a safe piece
of code only on the basis that there might be some other piece
of code in the program that does something wrong makes no sense.
Suggesting to the user to change the safe piece of code is
misleading and counterproductive.
There are plenty of architectures where the ABI does require the high part
to be extended in a particular way;
There is no high part when the wchar_t and wint_t types have
the same size, which they do not only in the case of interest but
also in all the other cases we know of. Again, unless you know
of a counterexample this point isn't relevant to the discussion.
I think the warning is the correct thing for anyone trying to write C as a
high-level language and be type-correct and properly check before doing
conversions that might change values unless those changes are actually
intended, and that warning rather than lesser warnings for "C as portable
assembler" is the appropriate default for format checking.
I certainly agree with this general philosophy. Unfortunately,
the wchar_t and wint_t types on the target of interest (i386
or ILP32 on x86_64) are defined in an unhelpful way that the
-Wformat checker normally uses to diagnose real (or potential)
problems that can do do come up with their underlying types.
They just can't come up with wchar_t and wint_t. Useful
warnings shouldn't pedantically enforce type rules in cases
where the rules serve no practical purpose or are loose enough
to allow for nonsensical implementations. This is a basic
principle that's been followed by the vast majority of GCC
warnings and that users have come to appreciate and rely on.
The underlying problem here (and I claim a bug) is simply that
the -Wformat code doesn't distinguish the wint_t typedef (and
in C, the wchar_t typedef as well) from their underlying types
and treats the typedefs the same. It should not, at least not
at the default warning level. I wouldn't object to retaining
the warning with -Wpedantic but otherwise it's unhelpful.
Martin
