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*********************@neverbox.com> wrote in message
news:mI*****************@newsread3.news.pas.earthl 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
mailto:al****@connect.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_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.

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

[Dan Pop]

In <mI*****************@newsread3.news.pas.earthlink. net> Kevin Goodsell <us*********************@neverbox.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.

[CBFalconer]

Kevin Goodsell wrote:

.... snip ...
It just so happens that in the specific case that prompted the question,
I was comparing the result of a strlen() call to an int that was used as
the destination variable for a sscanf %n format specifier. If you can
suggest a way to persuade sscanf to use size_t instead of int for %n, or
a way to persuade strlen() to return int, then I suppose your answer
would be useful.

I asked a pretty simple question. Why is everyone answering by
suggesting there's something wrong with the code? Let me clarify: I have
two variables that need to be compared. Assume the types are dictated
by something beyond my control. One is a signed type and one is an
unsigned type. I know the comparison is safe because the signed variable
is non-negative. But the compiler warns about it. I was seeking opinions
on how to handle this. Changing the types is not an option.

IIRC you did not originally specify that the integer was known to
be positive. In this case you can obviously cast it to unsigned
without worries, and be done with it. The usage deserves a
comment, just in case someone somewhere passes in a negative value
in future. For example, the scanf might fail, and thus never set
the integer value, which thus needs initializing or other
avoidance.

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

[CBFalconer]

Kevin Goodsell wrote:

CBFalconer wrote:

No, one should understand the data one is working with, and
program accordingly.

And I do understand the data. But the problem persists.

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

int main(void)
{
/* in the real program, buffer will be filled at run-time */
char buffer[] = " 0324 ";
long value;
int converted_items, scanned_chars = 0;

converted_items = sscanf(buffer, "%li %n", &value, &scanned_chars);

/* check if conversion failed: */
if (converted_items < 1 ||
(scanned_chars != 0 && scanned_chars < strlen(buffer)) )
{
return EXIT_FAILURE;
}
return EXIT_SUCCESS;
}

Unless I'm missing something, this code is perfectly fine. It should
convert the value from buffer to a long, allowing octal and hex
representations, and fail if the format is incorrect in any way. But the
comparison 'scanned_chars < strlen(buffer)' still causes a warning. The
question I am posing is, what do you consider the best way to handle a
situation like this?

I think the code is redundant. If sscanf ever scans past a '\0'
you have major problems with your library, so the strlen call is
pointless. I would write:

if (1 == sscanf(buffer, "%li%n", &value, &scanned_chars)) {
return EXIT_SUCCESS;
}
else {
return EXIT_FAILURE;
}

Note that I removed the space after %li. If you want to ensure a
terminating space you can also test:

if (' ' == buffer[scanned_chars]) ....

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

[Kevin Goodsell]

CBFalconer wrote:

I think the code is redundant. If sscanf ever scans past a '\0'
you have major problems with your library, so the strlen call is
pointless. I would write:

if (1 == sscanf(buffer, "%li%n", &value, &scanned_chars)) {
return EXIT_SUCCESS;
}
else {
return EXIT_FAILURE;
}

Note that I removed the space after %li. If you want to ensure a
terminating space you can also test:

if (' ' == buffer[scanned_chars]) ....

I believe you have misunderstood the intent of the code. The strlen()
call was to ensure that *all* characters were scanned (in other words,
that the buffer contained a valid integer and nothing else, except
possibly trailing or leading white space).

I'd like to go into more detail, but I have to run. It this is unclear,
I'll clarify later.

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

[Rudolf]

if (1 == sscanf(buffer, "%li%n", &value, &scanned_chars)) {
return EXIT_SUCCESS;
}
else {
return EXIT_FAILURE;
}

My question is off-topic from the original question, I'm curious if I'm
not understanding what sscanf returns. My documentation for the scanf
family says that the return value is "the number of input items
assigned." If that's the case, then the above code will return failure
if the sscanf gets a value for both "value" and "scanned_chars" since in
that case sscanf will return 2 and not 1.

Am I missing something?

[Jeremy Yallop]

Rudolf wrote:

if (1 == sscanf(buffer, "%li%n", &value, &scanned_chars)) {
return EXIT_SUCCESS;
}
else {
return EXIT_FAILURE;
}

My question is off-topic from the original question, I'm curious if I'm
not understanding what sscanf returns. My documentation for the scanf
family says that the return value is "the number of input items
assigned." If that's the case, then the above code will return failure
if the sscanf gets a value for both "value" and "scanned_chars" since in
that case sscanf will return 2 and not 1.

Am I missing something?

You're missing that %n is an exception: it's not counted as one of the
"input items assigned".

Jeremy.

[Irrwahn Grausewitz]

Rudolf <rt*****@bigfoot.com> wrote:

if (1 == sscanf(buffer, "%li%n", &value, &scanned_chars)) {
return EXIT_SUCCESS;
}
else {
return EXIT_FAILURE;
}

My question is off-topic from the original question, I'm curious if I'm
not understanding what sscanf returns. My documentation for the scanf
family says that the return value is "the number of input items
assigned." If that's the case, then the above code will return failure
if the sscanf gets a value for both "value" and "scanned_chars" since in
that case sscanf will return 2 and not 1.

Am I missing something?

Yup. C99 7.19.6.2#12:

[...]
Execution of a %n directive does not increment the assignment count
returned at the completion of execution of the fscanf function.
[...]

Regards
--
Irrwahn
(ir*******@freenet.de)

[Dan Pop]

In <rt***************************@netnews.attbi.com > Rudolf <rt*****@bigfoot.com> writes:

if (1 == sscanf(buffer, "%li%n", &value, &scanned_chars)) {
return EXIT_SUCCESS;
}
else {
return EXIT_FAILURE;
}

My question is off-topic from the original question, I'm curious if I'm
not understanding what sscanf returns. My documentation for the scanf
family says that the return value is "the number of input items
assigned." If that's the case, then the above code will return failure
if the sscanf gets a value for both "value" and "scanned_chars" since in
that case sscanf will return 2 and not 1.

Am I missing something?

Either your documentation is incredibly poor, or you didn't read it
carefully enough. What does it say about %n ?

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