This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/65446] Improve -Wformat-signedness
- From: "rnsanchez at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 09 Jun 2016 13:23:28 +0000
- Subject: [Bug c/65446] Improve -Wformat-signedness
- Auto-submitted: auto-generated
- References: <bug-65446-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65446
Ricardo Nabinger Sanchez <rnsanchez at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rnsanchez at gmail dot com
--- Comment #5 from Ricardo Nabinger Sanchez <rnsanchez at gmail dot com> ---
Created attachment 38666
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38666&action=edit
Simple test case
I understand the reasoning behind the implicit promotions.
Here is my rationale, asking for the warning to be emitted nonetheless: suppose
the first test in the test case I supplied is used in code that emits assembly
for an assembler. If the programmer mistakenly used %hu for a int16 type, and
that happened to generate a jump address, the implicit promotion would silently
hide an important error (possibly jumping to the opposite direction). The
printed-out value is clearly incorrect. It's not a compiler fault, but it just
so happens that the compiler is in the best position to warn the user that s/he
might run into problems. Let the programmer decide whether this should be
looked into (fixing his/her code) or if s/he will ignore.
In my case, I noticed this issue (silent signedess-mismatch) because I was
getting negative ports (IPv4/IPv6) on someone else's code, which was only a
visual nuisance. It would have been caught with the warning, but there was no
way I could get one. Clang failed to generate such a warning as well (and in
fact produces the same output).
The same happens with %hhd/%hhu specifiers when given mismatching
uint8_t/int8_t.
In short: please warn. Some cases will generate unexpected results (which are
not compilation errors), simply because the programmer used an incorrect format
specifier.