Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Comparing singed to unsinged warning

Reply
Thread Tools

Comparing singed to unsinged warning

 
 
Nevil Lesdog
Guest
Posts: n/a
 
      08-22-2007
What do you think is the best way to handle a compiler warning about
comparing an unsinged value to a singed 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?

 
Reply With Quote
 
 
 
 
Al Balmer
Guest
Posts: n/a
 
      08-22-2007
On Thu, 23 Aug 2007 01:09:39 +0200 (CEST), Nevil Lesdog <(E-Mail Removed)>
wrote:

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


Look at the code and make darned sure you understand why the warning
occurred, and why it was necessary to compare things of two different
type. Then, if you still think it was the right thing to do, use a
cast, which will at least indicate that you did it on purpose.
>
>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?


My opinion is that there's a very good chance that the code could be
better written.

--
Al Balmer
Sun City, AZ
 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      08-23-2007
Nevil Lesdog wrote:
>
> What do you think is the best way to handle a compiler warning about
> comparing an unsinged value to a singed value? Cast to silence it?
> Disable that warning altogether? Or just live with it?


None of those. Consider whether values should be 'singed' or not.

>
> 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).


If a negative value ever appears in either compareee, the
comparison is NOT safe.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
pete
Guest
Posts: n/a
 
      08-23-2007
Nevil Lesdog wrote:
>
> What do you think is the best way to handle a compiler warning about
> comparing an unsinged value to a singed value?
> Cast to silence it?


No.

> Disable that warning altogether?


No!

> Or just live with it?


No!!

> On one hand, the warning *could* be useful.


It most likely *is* useful.

Rewrite the code so that there is no singed/unsinged mismatch,
otherwise you might get signed by the heat.

> 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?


Change the sign type of one of your operands.

--
pete
 
Reply With Quote
 
Ark Khasin
Guest
Posts: n/a
 
      08-23-2007
pete wrote:
> Nevil Lesdog wrote:
>> What do you think is the best way to handle a compiler warning about
>> comparing an unsinged value to a singed value?
>> Cast to silence it?

>
> No.
>
>> Disable that warning altogether?

>
> No!
>
>> Or just live with it?

>
> No!!
>
>> On one hand, the warning *could* be useful.

>
> It most likely *is* useful.
>
> Rewrite the code so that there is no singed/unsinged mismatch,
> otherwise you might get signed by the heat.
>
>> 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?

>
> Change the sign type of one of your operands.
>

In Steven Colbert's words, Here is your today's word: Wrap it!

There are legitimate reasons why a mixed-signedness operations may be
necessary.
Imagine e.g. a function whose job is to scale and offset the argument,
limit the result from above and from below and output it to a DAC register.
An appropriate model for a DAC and perhaps for the lower and upper
limits is unsigned, whereas for scaling and offsetting a natural model
is signed.
At some point, a leap from one signedness to the other is necessary.

If the function is very small, a typecast (and a good comment) will do.
Otherwise, wrap it in a proof that you know what you are doing, like

#define INT2UINT(x) (assert((x)>=0),(unsigned)(x))

assuming you don't pass it an expression with side effects. Or make an
inline function to that effect.

-- Ark
 
Reply With Quote
 
Alexei A. Frounze
Guest
Posts: n/a
 
      08-23-2007
On Aug 22, 4:09 pm, Nevil Lesdog <(E-Mail Removed)> wrote:
> What do you think is the best way to handle a compiler warning about
> comparing an unsinged value to a singed 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?


You could compare them using a dedicated function like in this
program:

#include <stdio.h>
#include <limits.h>

int CmpSU (int s, unsigned int u)
// compares signed int s and unsigned int u;
// returns: -1 if s < u
// 0 if s == u
// 1 if s > u
{
if (s >= 0)
{
if ((unsigned int)s < u) return -1;
else if ((unsigned int)s > u) return 1;
return 0;
}
return -1;
}

struct
{
int s;
unsigned u;
} aTestValues[] =
{
{INT_MIN, 0},
{INT_MIN, 1},
{INT_MIN, INT_MAX},
{INT_MIN, UINT_MAX},
{-1, 0},
{-1, 1},
{-1, INT_MAX},
{-1, UINT_MAX},
{0, 0},
{0, 1},
{0, INT_MAX},
{0, UINT_MAX},
{1, 0},
{1, 1},
{1, INT_MAX},
{1, UINT_MAX},
{INT_MAX, 0},
{INT_MAX, 1},
{INT_MAX, INT_MAX},
{INT_MAX, UINT_MAX},
};

int main (void)
{
int i;
for (i = 0;
i < sizeof(aTestValues)/sizeof(aTestValues[0]);
i++)
{
int s = aTestValues[i].s;
unsigned int u = aTestValues[i].u;
printf ("%d %c %u\n",
s,
"<=>"[1+CmpSU(s,u)],
u);
}
return 0;
}


Alex

 
Reply With Quote
 
pete
Guest
Posts: n/a
 
      08-23-2007
Ark Khasin wrote:
>
> pete wrote:
> > Nevil Lesdog wrote:
> >> What do you think is the best way to handle a compiler warning about
> >> comparing an unsinged value to a singed value?
> >> Cast to silence it?

> >
> > No.
> >
> >> Disable that warning altogether?

> >
> > No!
> >
> >> Or just live with it?

> >
> > No!!
> >
> >> On one hand, the warning *could* be useful.

> >
> > It most likely *is* useful.
> >
> > Rewrite the code so that there is no singed/unsinged mismatch,
> > otherwise you might get signed by the heat.
> >
> >> 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?

> >
> > Change the sign type of one of your operands.
> >

> In Steven Colbert's words, Here is your today's word: Wrap it!
>
> There are legitimate reasons why a mixed-signedness operations may be
> necessary.
> Imagine e.g. a function whose job is to scale and offset the argument,
> limit the result from above and from below
> and output it to a DAC register.
> An appropriate model for a DAC and perhaps for the lower and upper
> limits is unsigned, whereas for scaling and offsetting a natural model
> is signed.
> At some point, a leap from one signedness to the other is necessary.
>
> If the function is very small,
> a typecast (and a good comment) will do.
> Otherwise, wrap it in a proof that you know what you are doing, like
>
> #define INT2UINT(x) (assert((x)>=0),(unsigned)(x))
>
> assuming you don't pass it an expression with side effects. Or make an
> inline function to that effect.


That's all over my head.
In my limited experience, I have never had to write code
that used a relational operator
with signed and unsigned operand types at the same time.

The one time that I encountered it in a project that I was working
on, the contract called for a clean compile and I had to fix it.
Aside from generating a warning, the implicit conversion
also rendered the controling expression of an "if" statement
as always flase. I don't remember any other details
except that I changed one of the types, so that
the error condition that the code was supposed to check for,
actually got checked for.

--
pete
 
Reply With Quote
 
Ark Khasin
Guest
Posts: n/a
 
      08-24-2007
pete wrote:
> Ark Khasin wrote:
>> pete wrote:
>>> Nevil Lesdog wrote:
>>>> What do you think is the best way to handle a compiler warning about
>>>> comparing an unsinged value to a singed value?
>>>> Cast to silence it?
>>> No.
>>>
>>>> Disable that warning altogether?
>>> No!
>>>
>>>> Or just live with it?
>>> No!!
>>>
>>>> On one hand, the warning *could* be useful.
>>> It most likely *is* useful.
>>>
>>> Rewrite the code so that there is no singed/unsinged mismatch,
>>> otherwise you might get signed by the heat.
>>>
>>>> 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?
>>> Change the sign type of one of your operands.
>>>

>> In Steven Colbert's words, Here is your today's word: Wrap it!
>>
>> There are legitimate reasons why a mixed-signedness operations may be
>> necessary.
>> Imagine e.g. a function whose job is to scale and offset the argument,
>> limit the result from above and from below
>> and output it to a DAC register.
>> An appropriate model for a DAC and perhaps for the lower and upper
>> limits is unsigned, whereas for scaling and offsetting a natural model
>> is signed.
>> At some point, a leap from one signedness to the other is necessary.
>>
>> If the function is very small,
>> a typecast (and a good comment) will do.
>> Otherwise, wrap it in a proof that you know what you are doing, like
>>
>> #define INT2UINT(x) (assert((x)>=0),(unsigned)(x))
>>
>> assuming you don't pass it an expression with side effects. Or make an
>> inline function to that effect.

>
> That's all over my head.
> In my limited experience, I have never had to write code
> that used a relational operator
> with signed and unsigned operand types at the same time.
>
> The one time that I encountered it in a project that I was working
> on, the contract called for a clean compile and I had to fix it.
> Aside from generating a warning, the implicit conversion
> also rendered the controling expression of an "if" statement
> as always flase. I don't remember any other details
> except that I changed one of the types, so that
> the error condition that the code was supposed to check for,
> actually got checked for.
>

I don't think there is any disagreement at all.
If you can refactor the code to avoid type mismatch, good. (And indeed
in most cases I've seen a type mismatch, it /is/ the result of sloppy
coding.)
There are cases though where signedness change is necessary.

-- Ark
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Unsinged types Jase Schick C Programming 35 09-07-2012 06:34 PM
Unsinged types Jase Schick C Programming 11 07-23-2012 10:12 PM
writing binary data whose size exceeds unsinged it mohammad.nabil.h@gmail.com C Programming 14 01-28-2006 12:18 PM
warning - comparing a signed value to an unsinged value Kevin Goodsell C Programming 30 10-22-2003 12:12 PM
Unsinged char to int Joseph Suprenant C Programming 2 08-18-2003 04:09 PM



Advertisments