Re: Multi-instructions macro and compiler warning

On 10/17/2011 12:58 PM, James Kuyper wrote:
On 10/17/2011 12:25 PM, christian.bau wrote:
On Oct 17, 4:07 pm, ImpalerCore<jadil...@xxxxxxxxx> wrote:
On Oct 16, 10:40 am, "christian.bau"
...
all members to zero. Another is a warning for "if (x>= 0&& x<=
100)" if the type of x happens to be unsigned. )

If 'x' is unsigned, I would think that one could use 'if (/*x>= 0
&&*/ x<= 100)' to document the condition while removing the warning,
as the 'x>= 0' condition is implicit from the use of an unsigned
type.
...
The point is that the warning in this case is completely pointless.

No - it catches a very common mistake: forgetting that the expression
being tested is incapable, because of it's type, of failing the test.
This is very often a sign that the user wasn't thinking about the fact
that the expression was unsigned; and is often accompanied by code that
will not do what the author expected it to do, for that same reason.
That this was not true in this particular case doesn't invalidate
generation of the warning.

In a related case, a colleague once got a warning that

if (thing.field > 0) foo(); else bar();

.... was a vacuous test which would always result in calling bar(),
never foo(). Investigating, he found

struct { int field : 1; /*...*/ } thing;

The catch is that a plain `int' bit-field may be signed or unsigned
at the compiler's discretion. On the compiler where the code was first
developed such bit-fields were unsigned, so `field' could store either
zero or one and the `if' made sense. The compiler that issued the
warning treated bit-fields as signed, so `field' had one sign bit and
no value bits; its only possible (two's complement) values were zero
and minus one. Adding an `unsigned' fixed things.

Thus, the warning about restricted range led to the detection of
an actual portability bug that had been sitting in the code since
whoknowswhen. That's far from "completely pointless."

--
Eric Sosman
esosman@xxxxxxxxxxxxxxxxxxxx
.

Relevant Pages

  • Re: Q: Local variables initialization shortcut.
    ... At least I want to initialise all of them to zero to ... and the compiler can usually be told ... gcc compiler, for example, has the "-Wuninitialized" flag (which ... or a compile-time warning drawing your attention to a potential ...
    (comp.lang.c)
  • Re: fork pagesize patch
    ... and the compiler complaining that "a" can be zero. ... A compiler that does that is being silly. ... at least the compiler isn't totally buggy if it's just a warning. ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: Nested Generate Statement in VHDL
    ... Now if I set N_TX to zero, Modelsim compiler issues a warning about the ... inner generate, saying "Range 0 to -1 is null". ... Can I safely ignore this warning message? ...
    (comp.arch.fpga)
  • Re: Multi-instructions macro and compiler warning
    ... never foo(). ... On the compiler where the code was first ... developed such bit-fields were unsigned, ... the warning about restricted range led to the detection of ...
    (comp.lang.c)
  • Re: Uninitialised fields in structures
    ... I was recently surprised by the compiler's warning concerning this code: ... The compiler actually claimed that t.len was uninitialised. ... explicitly initialise it, but I was under the impression that it should be ... initialised with zero). ...
    (comp.lang.c)