Velocity Reviews > unsigned == signed ?

# unsigned == signed ?

Keith Thompson
Guest
Posts: n/a

 10-12-2011
Quentin Pope <(E-Mail Removed)> writes:
> On Tue, 11 Oct 2011 14:34:29 -0700, Keith Thompson wrote:
>> Quentin Pope <(E-Mail Removed)> writes:

[...]
>>> uint x = 1;
>>> int y = -1;
>>> if (x == y)
>>> printf("EQUAL");
>>> else
>>> printf("NOT EQUAL");
>>>
>>> will print NOT EQUAL since y is converted to an unsigned int and
>>> becomes 0

>>
>> No, it will print NOT EQUAL because y is converted to an unsigned int
>> and becomes UINT_MAX (typically 4294967295), which is not equal to 1.
>> You'd get the same result if "==" did a bitwise comparison.

>
> true, my mistake.
> however the values are converted first. to prove it, try this
> long x = -1; /* (32 bit, signed) */
> unit y = -1; /* (16 bit, unsigned) */

What makes you think that long is 32 bits and uint (unsigned int?) is
16 bits? They're *at least* those widths, but they could be wider.
(I suspect that int is actually 32 bits on your system.)

> if (x == y) printf("EQUAL");
> will print EQUAL !

Not if long is wider than int, as you assert. (More precisely, not
if long can represent all the values of unsigned int.) On such
a system, y will be initialized to UINT_MAX, which is 65535.
In the comparison, the "usual arithmetic conversions" will promote
the value of y from unsigned int to (signed) long, resulting in
an equality comparison between 65535 and -1, both of type long.
It will not print "EQUAL".

On the other hand, if int and long are both 32 bits, then both x
and y are converted to unsigned long, so the comparison is between
ULONG_MAX and ULONG_MAX; in that case, it will print "EQUAL".

And why do you insist on using the name "uint"? We've said before
that there is no such predefined type in C. If you mean "unsigned
int", please say "unsigned int". If you really want to call it
"uint", provide a typedef. (For all we know, "uint" could be a
typedef for _Bool.)

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Phil Carmody
Guest
Posts: n/a

 10-13-2011
Raj Pashwar <(E-Mail Removed)> writes:
> int main()
> {
> uint x = -1;
> int y = -1;
> if (x == y)
> printf("EQUAL");
> else
> printf("NOT EQUAL");
> }
>
> This code prints "EQUAL". Does this mean that bit comparison is done for
> the
> equality test? If it doesn't can you give me an example that shows bit
> comparison isn't done? I also wanted to know if we can assign a number to
> uint & int variables such that "unit var != int var". Thanks so much

C will only compare equal types. In order to perform what looks
like a comparison between unequal types, an implicit conversion
is made first such that the things actually being compared are
the same type. See the description of the '==' operator in the

Phil
--
"Religion is what keeps the poor from murdering the rich."
-- Napoleon

Phil Carmody
Guest
Posts: n/a

 10-13-2011
Ben Bacarisse <(E-Mail Removed)> writes:
> Quentin Pope <(E-Mail Removed)> writes:
>
> > On Tue, 11 Oct 2011 19:43:03 +0000, Raj Pashwar wrote:
> >> int main()
> >> {
> >> uint x = -1;
> >> int y = -1;
> >> if (x == y)
> >> printf("EQUAL");
> >> else
> >> printf("NOT EQUAL");
> >> }
> >>
> >> This code prints "EQUAL". Does this mean that bit comparison is done for
> >> the
> >> equality test? If it doesn't can you give me an example that shows bit
> >> comparison isn't done?

> >
> > no ! unsigned int, and signed int are very different the way they are
> > represented in bits. therefore, when you to compare the 2 different types
> > (like comparing apples and oranges) one of them has to be converted, in
> > this
> > case, the 'int' is converted to a 'uint', and becomes 0, since unsigned
> > numbers cannot be less then zero.

>
> Not zero, but UINT_MAX.

He looks like he's under the misapprehension that the conversion is a
saturating one (anything that goes out of bounds gets mapped onto the
value just inside the bound that was exceeded.

So I think the better correction is the mathematical expression
UINT_MAX+1+x
Which for x==-1 is UINT_MAX, as you say.
But for x==2 it's UINT_MAX-1, etc.

> > and besides, the == operator it *not* a bit comparison operator, it is a
> > variable comparison operator, if you want to do bit comparison you use the
> > bitwise operators, &,|,^,~. (and, or, exclusive or, not. respectively)
> >
> >> I also wanted to know if we can assign a number
> >> to uint & int variables such that "unit var != int var". Thanks so much

> >
> > yes, if unit var = 1, and int var is any value other than 1 (-1, 0, -10,
> > 10,
> > 100, whatever) then they will be 'not equal' if you use the operator '!='
> > for example:
> >
> > uint x = 1;
> > int y = -1;
> > if (x == y)
> > printf("EQUAL");
> > else
> > printf("NOT EQUAL");
> >
> > will print NOT EQUAL since y is converted to an unsigned int and becomes
> > 0

>
> See above!

Yup, I'm sure he thinks it saturates.

Phil
--
"Religion is what keeps the poor from murdering the rich."
-- Napoleon

Ben Bacarisse
Guest
Posts: n/a

 10-13-2011
Phil Carmody <(E-Mail Removed)> writes:

> Ben Bacarisse <(E-Mail Removed)> writes:
>> Quentin Pope <(E-Mail Removed)> writes:
>>
>> > On Tue, 11 Oct 2011 19:43:03 +0000, Raj Pashwar wrote:
>> >> int main()
>> >> {
>> >> uint x = -1;
>> >> int y = -1;
>> >> if (x == y)
>> >> printf("EQUAL");
>> >> else
>> >> printf("NOT EQUAL");
>> >> }
>> >>
>> >> This code prints "EQUAL". Does this mean that bit comparison is done for
>> >> the
>> >> equality test? If it doesn't can you give me an example that shows bit
>> >> comparison isn't done?
>> >
>> > no ! unsigned int, and signed int are very different the way they are
>> > represented in bits. therefore, when you to compare the 2 different types
>> > (like comparing apples and oranges) one of them has to be converted, in
>> > this
>> > case, the 'int' is converted to a 'uint', and becomes 0, since unsigned
>> > numbers cannot be less then zero.

>>
>> Not zero, but UINT_MAX.

>
> He looks like he's under the misapprehension that the conversion is a
> saturating one (anything that goes out of bounds gets mapped onto the
> value just inside the bound that was exceeded.
>
> So I think the better correction is the mathematical expression
> UINT_MAX+1+x
> Which for x==-1 is UINT_MAX, as you say.
> But for x==2 it's UINT_MAX-1, etc.

It is indeed better, but these details had already been explained by
other replies to the OP when I posted. All I was doing was pointing out
an uncorrected detail in another reply. (And I was feeling lazy.)

<snip>
--
Ben.