recently I have come across a gcc warning that I do no understand.
I looked it up in the man page, and sure enough it states that a
warning is issued if '-W' is in effect when
"An unsigned value is compared against zero with `>' or `<='"
Now why is this? As I see it, an unsigned value may or may not be
greater than zero, so checking that is perfectly reasonable.
I would understand issuing a message for a comparison against zero
with `>=' or `<', because these would always yield the same value. In
that case the programmer was probably a little confused.
I tried to come up with an explanation containing the conversion of
the unsigned value to signed, and a possible resulting sign change.
But then a comparison against any number (not only against zero)
would yield surprising results.
So please, can anybody enlighten me about the reason for this warning?
In case it matters, I am running gcc 2.95.2.
And I know, once I read the answer, I am going to feel incredibly
stupid ...
Thanks in advance
Ulrich
Did you write 'unsigned < 0' ? Since a number smaller than 0 is
negative, and an unsigned can't be negative, you get a warning ...
Wim
>
>Did you write 'unsigned < 0' ? Since a number smaller than 0 is
>negative, and an unsigned can't be negative, you get a warning ...
>
>Wim
Nope,
I wrote 'unsigned > 0'. That resulted in a warning, in accordance
with the man page. I just don't see a reason for that, I really wanted
to know if the values was greater than zero.
Comparing an unsigned value against zero with '<' does _not_ yield
a warning, if I believe the documentation (I did not try it).
Ulrich
> Hello,
>
> recently I have come across a gcc warning that I do no understand.
> I looked it up in the man page, and sure enough it states that a
> warning is issued if '-W' is in effect when
>
> "An unsigned value is compared against zero with `>' or `<='"
>
> Now why is this? As I see it, an unsigned value may or may not be
> greater than zero, so checking that is perfectly reasonable.
I think if you test this that you'll find that the implementation
agrees with your intuition, which indicates it's a documentation bug.
Robert
--
The above are my opinions,
and my opinions only.
I believe that in ANSI C, the numeric constant 0 is treated as a signed
int. The compiler may be complaining about performing a relational
operation between a signed and unsigned variable. Have you tried using
0u? Also, you could change your test to != 0 (which is equivalent in this
specific case).
Art
I imagine they just wanted the same warning text to work for...
0 > unsigned (always false)
...as well as for...
unsigned <= 0 (always false)
OR it may be the case that gcc's optimisations often reverse (a > b) into
(b <= a), and it may not be possible for gcc to know what was actually in
the original code after this canonicalization has been performed. What
message does it give when you try..
unsigned >= 0 (always true)
...? Does it also refer to (0 <= unsigned), perhaps ?
DaveK
--
They laughed at Galileo. They laughed at Copernicus. They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.
>Ulrich Hagen <Ulrich...@Med.Siemens.de> writes:
>
snip...
>
>I think if you test this that you'll find that the implementation
>agrees with your intuition, which indicates it's a documentation bug.
>
>Robert
Oops,
I stand corrected. *blush*, You are absolutely right. A colleague
asked me about that warning he got, I said I can't explain it, but the
man page agrees that the compiler would output such a warning.
What I did not know was that the used compiler was _not_ gcc, but
ccc (a Compaq compiler for the Alpha).
So gcc is not a problem, it issues only warnings like
warning: comparison of unsigned expression >= 0 is always true
warning: comparison of unsigned expression < 0 is always false
which is abolutely reasonable.
Interesting coincidence, the man page of one compiler stating
something unexplainable that another compiler does!
Well, next time I will double and triple check what I see before
asking stupid questions in public.
Thanks to all that contributed.
BTW, has nobody noticed this error in the man page before?
Can/should I contact someone so the documentation will be improved?
Ulrich