warning - comparing a signed value to an unsinged value

[Kevin Goodsell]

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.

[T.M. Sommers]

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.

[Alex Vinokur]

"Kevin Goodsell" <us************ *********@never box.com> wrote in message
news:mI******** *********@newsr ead3.news.pas.e arthlink.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
mailto:al****@c onnect.to
http://mathforum.org/library/view/10978.html
news://news.gmane.org/gmane.comp.lang.c++.perfometer
=============== =============== =======

[David Rubin]

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

[Kevin Goodsell]

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_typ e))
{
/* ... */
}
}

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.

[CBFalconer]

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 (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[Dan Pop]

In <mI************ *****@newsread3 .news.pas.earth link.net> Kevin Goodsell <us************ *********@never box.com> writes:

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?

I prefer not to enable this warning. It never revealed a real bug in my
code and I'd never use a cast for the sole reason of silencing a warning.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[pete]

Kevin Goodsell wrote:

Why is everyone answering by
suggesting there's something wrong with the code?

The warning suggests that a better choice of types may be available.
I understand that that isn't the case.

--
pete

[Sheldon Simms]

On Tue, 21 Oct 2003 06:40:26 +0000, Kevin Goodsell wrote:

Changing the type is not an option. As I told pete, 'SomeFunc' is
actually sscanf() with a %n format specifier.

The value is non-negative, but the interface requires an int. This is
beyond my control. If you want to file a defect report suggesting that
the %n format specifier for the *scanf functions should expect a size_t
instead of an int, be my guest. While you're at it, I believe there are
a few other standard library functions that use ints where size_t would
probably be more appropriate.

Maybe I should have been more clear in my post. I intended for you to
assume the types were dissimilar for some good reason and could not be
easily changed to similar types.

Yes, in your defect report be sure to include a note stating that Dennis
Ritchie (or whoever defined it) is an idiot for defining *scanf() the
way he did.

I feel I owe you an apology Kevin! It really was stupid of me to
attempt to answer your question by considering the different possibilites.
I should have realized right away that you are an expert. After all,
novices and inexperienced programmers hardly ever post anything in
comp.lang.c, and even if they did, I should have been able to recognize
your expertise by clairvoyantly reading your aura. I promise it will
never happen again. Please forgive me.

-Sheldon

[Kevin Goodsell]

Sheldon Simms wrote:

I feel I owe you an apology Kevin! It really was stupid of me to
attempt to answer your question by considering the different possibilites.
I should have realized right away that you are an expert. After all,
novices and inexperienced programmers hardly ever post anything in
comp.lang.c, and even if they did, I should have been able to recognize
your expertise by clairvoyantly reading your aura. I promise it will
never happen again. Please forgive me.

Sorry, I was feeling a bit frustrated with the replies I was getting. I
probably should have been more clear in my first message, and I
definitely should not have been as harsh in my replies as I was. I've
actually spent quite a bit of time here (though not lately), and getting
the "newbie treatment" irritated me, but it's probably my own fault for
not being clear enough. Again, I apologize.

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