«

What do you think is the best way to handle a compiler warning about
comparing an unsigned value to a signed value? Cast to silence it?
Disable that warning altogether? Or just live with it?

On one hand, the warning *could* be useful. Most of the time I get it in
cases where I know the comparison is safe, but it's not hard to imagine
that this won't always be the case. This makes disabling it undesirable.
Casting is a workable solution, but I worry that changes in the code
later could introduce errors that go undetected due to the cast. And I
think we all hate not having a "clean" compile (if only because having a
bunch of warnings that you expected makes it more difficult to spot the
ones you didn't expect).

What is your opinion?

Thanks.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

"Kevin Goodsell" <> wrote in message
news:mIWkb.3815$ ink.net...
> What do you think is the best way to handle a compiler warning about
> comparing an unsigned value to a signed value?
[snip]

If you are using gcc then ;
gcc -W -Wall foo.c

--
=====================================
Alex Vinokur
private.php?do=newpm&u=
http://mathforum.org/library/view/10978.html
news://news.gmane.org/gmane.comp.lang.c++.perfometer
=====================================

Kevin Goodsell wrote:
> What do you think is the best way to handle a compiler warning about
> comparing an unsigned value to a signed value? Cast to silence it?
> Disable that warning altogether? Or just live with it?

You could always fix the code so that you aren't comparing a signed to
an unsigned.

Kevin Goodsell wrote:
>
> What do you think is the best way to handle a compiler warning about
> comparing an unsigned value to a signed value? Cast to silence it?
> Disable that warning altogether? Or just live with it?

IME, this usually occurs when you have a function which checks an int
value against some range, typically derived via sizeof (size_t, which is
unsigned). My suggestion, in this case, is to fix your functions so that
you use size_t for ranges and indices.

/david

--
Andre, a simple peasant, had only one thing on his mind as he crept
along the East wall: 'Andre, creep... Andre, creep... Andre, creep.'
-- unknown

T.M. Sommers wrote:
> Kevin Goodsell wrote:
>
>> What do you think is the best way to handle a compiler warning about
>> comparing an unsigned value to a signed value? Cast to silence it?
>> Disable that warning altogether? Or just live with it?
>
>
> You could always fix the code so that you aren't comparing a signed to
> an unsigned.
>

That's not always possible without introducing new variables.

int SomeFunc(int *dest); /* returns error code, writes value to *dest */

int i;
if (SUCCESS == SomeFunc(&i))
{
if (i < sizeof(some_type))
{
/* ... */
}
}

I can't very well get an unsigned type from SomeFunc, nor can I cause
sizeof() to result in a signed type. The only way to make the comparison
deal with like types would be to add a new variable that logically
shouldn't exist. This is hardly any better than casting in the comparison.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Kevin Goodsell wrote:
>
> What do you think is the best way to handle a compiler warning
> about comparing an unsigned value to a signed value? Cast to
> silence it? Disable that warning altogether? Or just live with it?
>
> On one hand, the warning *could* be useful. Most of the time I get
> it in cases where I know the comparison is safe, but it's not hard
> to imagine that this won't always be the case. This makes
> disabling it undesirable. Casting is a workable solution, but I
> worry that changes in the code later could introduce errors that
> go undetected due to the cast. And I think we all hate not having
> a "clean" compile (if only because having a bunch of warnings that
> you expected makes it more difficult to spot the ones you didn't
> expect).
>
> What is your opinion?

Spend a little time thinking. Assume we are talking about signed
and unsigned ints. Now, if the unsigned is larger than INT_MAX,
it is obviously larger than the int. If the int is negative, it
is obviously smaller than the unsigned. Having eliminated these
cases you can safely cast the int into unsigned, and then
compare. In fact, all you need to eliminate is the negative case.

--
Chuck F () ()
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

"CBFalconer" <> wrote in message
news:...
> Kevin Goodsell wrote:
> >
> > What do you think is the best way to handle a compiler warning
> > about comparing an unsigned value to a signed value? Cast to
> > silence it? Disable that warning altogether? Or just live with it?

(snip)

> Spend a little time thinking. Assume we are talking about signed
> and unsigned ints. Now, if the unsigned is larger than INT_MAX,
> it is obviously larger than the int. If the int is negative, it
> is obviously smaller than the unsigned. Having eliminated these
> cases you can safely cast the int into unsigned, and then
> compare. In fact, all you need to eliminate is the negative case.

Say one wants to compare a return value from a function to sizeof(some
struct). It would seem safer to cast sizeof to int, unless one could
realistically expect sizeof to be greater than MAX_INT. Casting the int to
unsigned will cause negative return values to fail a less than test. Though
in some cases that might be a good thing.

I believe one should understand the result of both types of comparisons, and
choose the appropriate one.

-- glen

On Mon, 20 Oct 2003 20:56:33 +0000, Kevin Goodsell wrote:

> T.M. Sommers wrote:
>> Kevin Goodsell wrote:
>>
>>> What do you think is the best way to handle a compiler warning about
>>> comparing an unsigned value to a signed value? Cast to silence it?
>>> Disable that warning altogether? Or just live with it?
>>
>>
>> You could always fix the code so that you aren't comparing a signed to
>> an unsigned.
>
> That's not always possible without introducing new variables.
>
> int SomeFunc(int *dest); /* returns error code, writes value to *dest */
>
> int i;
> if (SUCCESS == SomeFunc(&i))
> {
> if (i < sizeof(some_type))
> {
> /* ... */
> }
> }
>
> I can't very well get an unsigned type from SomeFunc, nor can I cause
> sizeof() to result in a signed type. The only way to make the comparison
> deal with like types would be to add a new variable that logically
> shouldn't exist. This is hardly any better than casting in the comparison.

In this case, you are comparing the value in 'i' with a size_t.
You shouldn't be doing this at all unless you *know* that the
value in 'i' is unsigned. If you know this, then you should make
'i' unsigned (and change the name to something better like 'size').

Your problem is really that SomeFunc() wants a pointer to (signed)
int, when the value it is storing there is unsigned. The solution is
to change SomeFunc(). If you can't do that, but you know *for sure*
that SomeFunc() never writes a signed value into 'i', then cast the
argument to SomeFunc().

If, however, you don't know for sure that SomeFunc() behaves properly
(you don't have the souce code, for example), then you need to give
SomeFunc() a pointer to int, and then check to make sure that it isn't
negative before comparing it to sizeof(some_type).

So take your pick:

unsigned int size;
if (SUCCESS == SomeFunc(&(int)size))
{
if (size < sizeof(some_type))
...
}


int signed_size; /* Bogus, but SomeFunc() author is an idiot */
if (SUCCESS == SomeFunc(&signed_size))
{
if (signed_size < 0) return ERROR;
if ((unsigned int)signed_size < sizeof(some_type))
...
}

-Sheldon

In article <>
Sheldon Simms <> writes:
>In this case, you are comparing the value in [signed int] 'i' with
>a size_t. You shouldn't be doing this at all unless you *know* that the
>value in 'i' is unsigned.

Not necessarily: another option is "if a negative value of i is
supposed to be considered greater than the size_t value, which you
know is not `overflow-able'". That is, you know for certain that,
in:

i < u

the value in u is less than INT_MIN + UINT_MAX + 1, so that
all values of i in [INT_MIN..-1] result in values in the range
[INT_MIN + UINT_MAX + 1 .. UINT_MAX], which is less than u.

This test can be (re)written as:

i < 0 || i < (int)u

but this is probably even worse. Or you could write it as:

i >= 0 && (unsigned)i < u

but this is redundant.

(In the BSD kernel, we have a lot of code of the form:

if (i >= fdp->max || (fp = fdp->openfiles[i]) == NULL)
return (EBADF);

where fdp->max is known to be unsigned, so that signed-int interfaces
cannot use negative-valued file descriptors to escape system
security. Casting i gets rid of the warning; adding the redundant
"i < 0 ||" does not get rid of the warning and just makes the
compiler work hard to remove the redundant test. So, despite
my distaste for unnecessary casts, we either cast or live with
the warning.)

>If you know this, then you should make
>'i' unsigned (and change the name to something better like 'size').

That would be nice, but the interface is set in stone (or in POSIX
anyway, which is close enough to stone ).

>Your problem is really that SomeFunc() wants a pointer to (signed)
>int, when the value it is storing there is unsigned. The solution is
>to change SomeFunc(). If you can't do that, but you know *for sure*
>that SomeFunc() never writes a signed value into 'i', then cast the
>argument to SomeFunc().

Personally, I consider adding pointer casts -- i.e.,

unsigned int ui;
x = SomeFunc((int *)&ui);
... now use the "unsigned" value in ui ...

-- to be the worst of the various alternatives.

>If, however, you don't know for sure that SomeFunc() behaves properly
>(you don't have the souce code, for example), then you need to give
>SomeFunc() a pointer to int, and then check to make sure that it isn't
>negative before comparing it to sizeof(some_type).

Or, as I said above, guarantee that the test "i < 0 ||" is redundant
(as we do), and then either cast or live with the warning.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.

On Mon, 20 Oct 2003 19:07:56 -0400, Sheldon Simms wrote:

> unsigned int size;
> if (SUCCESS == SomeFunc(&(int)size))

if (SUCCESS == SomeFunc((int *)size))

> {
> if (size < sizeof(some_type))
> ...
> }