Unsigned/Signed Mismatch

[MiniDisc_2k2]

Okay, here's a question about the standard. What does it say about
unsigned/signed mismatches in a comparison statement:

char a = 3;
unsigned char b = 255;
if (a<b)

Now what's the real answer here? If a is converted to unsigned, then b>a.
But, if b is converted to signed,then a>b. What's the correct coversion
(what is the compiler supposed to do?)

 

[Ioannis Vranos]

Integral promotions are applied to both operands here. Both
'a' and 'b' are converted to 'int', if 'int' can represent the
values of the source type, or to 'unsigned' otherwise. In
a usual scenario where sizeof(int) > 1, both 'a' and 'b' shall
become 'int' and then compared. There is no need for the mis-
match warning, IMHO. If sizeof(int) == 1, then not all unsigned
char values can be represented by 'int'. In such case both 'a'
and 'b' will be converted to 'unsigned int'. In that case, if
'a' is negative, you will not get the intended comparison for
the unsigned value for a negative 'a' will be formed by copying
the bit pattern (whatever that results into). Imagine that if
'a' is -1, and 'b' is 255, and sizeof(int)==1, and you're on
a two's complement machine, unsigned(a) will be at least 65535.
And you will get (a < b) == false. In this case the warning
is warranted, IMHO.

?

In your hypothetical scenario (sizeof(char)==sizeof(int)) if you have a
signed char it will be converted to long, not to unsigned int.






--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

 

[Ioannis Vranos]

Okay, here's a question about the standard. What does it say about
unsigned/signed mismatches in a comparison statement:

char a = 3;
unsigned char b = 255;
if (a<b)

Now what's the real answer here? If a is converted to unsigned, then b>a.
But, if b is converted to signed,then a>b. What's the correct coversion
(what is the compiler supposed to do?)

At first keep in mind that char (differently from other "plain" integer
types) can be either signed or unsigned. If you want one of the two in
specific, you have to declare it explicitly (e.g. signed char a=3).


Assuming you wish your above code to be:


signed char a = 3;
unsigned char b = 255;
if (a<b)


Both unsigned char and signed char get converted to int during the
expression evaluation.


So in summary, a either signed char either unsigned gets converted to int.





--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

 

[Ioannis Vranos]

Why would it. The signed char is promoted to int, the unsigned char is
promoted to unsigned int (4.5), and then since one is unsigned, the ohter
is converted to unsigned. long doesn't ever enter into the discussion.

Yes i just checked the standard and you are right. However that would be a
stupid compiler. The standard allows stupid implementations but i do not
think such an implementation exists out there.





--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

 

[Francis Glassborow]

Okay, here's a question about the standard. What does it say about
unsigned/signed mismatches in a comparison statement:

char a = 3;
unsigned char b = 255;
if (a<b)

Now what's the real answer here? If a is converted to unsigned, then b>a.
But, if b is converted to signed,then a>b. What's the correct coversion
(what is the compiler supposed to do?)

No, the normal integral promotions are applied first Which only becomes
mildly interesting on systems where all integral types are the same
size.

 

[MiniDisc_2k2]

At first keep in mind that char (differently from other "plain" integer
types) can be either signed or unsigned. If you want one of the two in
specific, you have to declare it explicitly (e.g. signed char a=3).


Assuming you wish your above code to be:


signed char a = 3;
unsigned char b = 255;
if (a<b)


Both unsigned char and signed char get converted to int during the
expression evaluation.


So in summary, a either signed char either unsigned gets converted to int.

Well actually I was using chars only to save my mind from calculating it all
out. Let's try again.

I also intended this code to be used on a two's complement machine.

Use this:

signed int a = 3;
unsigned int b = -1; /* thus being the highest number represented by
unsigned int*/
if (b<a)

Now. If b were converted to a signed integer, b<a would be -1<3 == true. If
a were converted to an unsigned integer, we would get 65535 < 3 == false (in
16-bit environment). Which representation does it follow. Does it proceed
like the char conversion, where it is converted to a signed int? Is this at
all standardized, or does the compiler get to pick?

 

[Andy Sawyer]

on Thu, 10 Jul 2003 20:34:29 +0000 (UTC),

Okay, here's a question about the standard. What does it say about
unsigned/signed mismatches in a comparison statement:

char a = 3;
unsigned char b = 255;
if (a<b)

Now what's the real answer here? If a is converted to unsigned, then b>a.
But, if b is converted to signed,then a>b

What's the correct coversion
(what is the compiler supposed to do?)

5.9p2 tells us that the usual arithmetic conversions (5p9) are performed.

4.5p1 tells us that 'a' is promoted to signed int,

It also tells us that b is promoted to either signed int or unsigned
int, depending on the implementation, specifically:

,----
| An rvalue of type char, signed char, unsigned char, short int, or
| unsigned short int can be converted to an rvalue of type int if int
| can represent all the values of the source type; otherwise, the source
| rvalue can be converted to an rvalue of type unsigned int.
`----

Either way, it will still have the value 255 (I assume from your magic
number of 255, you're thinking of a platform with 8-bit characters and
you're concerned about sign-extention? Not a problem here

If b has been promoted to signed int (such as in an 8-bit char
environment), then the comparison is performed with signed integers, so
(a<b) yields true.

If b has been promoted to unsigned int, a is then also converted to
unsigned int (5p9) and the comparison is performed using unsigned
integers, and again (a<b) yields true.

In this last case (b promoted to unsigned, a converted to unsigned),
then the result is highly dependant on the actual value of a, as 4.7p3
says:

,----
| If the destination type is signed, the value is unchanged if it can be
| represented in the destination type (and bitfield width); otherwise,
| the value is implementation-defined.
`----

Since, in your example, a == 3, then it can comfortable fit inside an
unsigned int and hence is unchanged.

At least, that's the way _I_ read the standard

Regards,
Andy S.

 

[Andy Sawyer]

on Thu, 10 Jul 2003 23:10:49 +0000 (UTC),

Well actually I was using chars only to save my mind from calculating it all
out. Let's try again.

I also intended this code to be used on a two's complement machine.

Use this:

signed int a = 3;
unsigned int b = -1; /* thus being the highest number represented by
unsigned int*/

No, it's a signed integer converted to an unsigned integer. And it's a
value that the unsigned target cannot represent, so the value of b is
actually implementation-defined.
If you *actually* want the highest value represented by an unsigned
integer, then write::

if (b<a)

Now. If b were converted to a signed integer

Which it won't be.

b<a would be -1<3 == true. If
a were converted to an unsigned integer

It will be.

we would get 65535 < 3 == false (in
16-bit environment). Which representation does it follow. Does it proceed
like the char conversion, where it is converted to a signed int? Is this at
all standardized, or does the compiler get to pick?

It's standardized in detail, see:

4.5 Integral Promotions
4.7 Integral Conversions
5p9 "the usual suspects^H^H^H^H^H^H^H^H arithmetic conversions"

What the compiler *can* pick is the result of the conversion from signed
to unigned types if the value of the signed type cannot be represented
in the unsigned type (see 4.7p3)

Regards,
Andy S

 

[Ben Hutchings]

The C++ standard says:

[conv.prom] 4.5 Integral promotions
1 An rvalue of type char, signed char, unsigned char, short int, or
unsigned short int can be converted to an rvalue of type int if int can
represent all the values of the source type; otherwise, the source
rvalue can be converted to an rvalue of type unsigned int.

The (1) is your case.

<snip>

No. Do you see "signed int" in that list?

 

[Andy Sawyer]

on Thu, 10 Jul 2003 21:55:32 +0000 (UTC),

At first keep in mind that char (differently from other "plain" integer
types) can be either signed or unsigned. If you want one of the two in
specific, you have to declare it explicitly (e.g. signed char a=3).

Remember that char, signed char and unsigned char are three disticnt
types. FWIW, if I'm using the value in an arithmetic context, then I
always write either signed char or unsigned char. If I'm using it to
represent text elements, then I write char. And I probably wouldn't
write:

char a = 3;

I'd write

char a = '\003';

or, more likely - given my current project:

char a = ASCII::ETX;

Assuming you wish your above code to be:

signed char a = 3;
unsigned char b = 255;
if (a<b)

I suspect if he'd wished that, he'd have written that.

Both unsigned char and signed char get converted to int during the
expression evaluation.

In fact, unsigned char may be promoted to unsigned int (depending on the
environment).

So in summary, a either signed char either unsigned gets converted to
int.

I had trouble parsing that - I assume you meant

"So in summary, either a signed char or unsigned char gets converted to
int."
?

If that is what you meant, then it isn't strictly true on all
platforms. Please see my other post for why

Regards,
Andy S.

 

[Ioannis Vranos]

No, that would be a conforming compiler. One that did anything else
in this case would be the stupid one, because it would be
non-conforming.

Let me clarify what i mean, a compiler where sizeof(int)==1 would be a
conforming, stupid compiler.






--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

 

[Victor Bazarov]

be


Let me clarify what i mean, a compiler where sizeof(int)==1 would be a
conforming, stupid compiler.

Imagine how the creators of the compilers for many different
Digital Signal Processors feel when they read your opinion
of their compiler. Yes, on many DSPs sizeof(long) ==
sizeof(int) == sizeof(short) == 1. Their byte has 32 bits
in it.

If you haven't worked with something, it doesn't mean that
it's "stupid"...

 

[William M. Miller]

on Thu, 10 Jul 2003 23:10:49 +0000 (UTC),


No, it's a signed integer converted to an unsigned integer. And it's a
value that the unsigned target cannot represent, so the value of b is
actually implementation-defined. ....
What the compiler *can* pick is the result of the conversion from signed
to unigned types if the value of the signed type cannot be represented
in the unsigned type (see 4.7p3)

Wrong paragraph. 4.7p3 deals with conversion to signed types
("if the destination type is signed..."), and the result is
implementation-defined, as you say. The description of
conversion to an unsigned type is in 4.7p2, and the result is
defined by the Standard, not by the implementation:

If the designation type is unsigned, the resulting value is
the least unsigned integer congruent to the source integer
(modulo 2**n where n is the number of bits used to represent
the unsigned type). [Note: In a two's complement
representation, this conversion is conceptual and there is
no change in the bit pattern (if there is no truncation). ]

-- William M. Miller

 

[Ron Natalie]

Okay, here's a question about the standard. What does it say about
unsigned/signed mismatches in a comparison statement:

char a = 3;
unsigned char b = 255;
if (a<b)

Now what's the real answer here? If a is converted to unsigned, then b>a.
But, if b is converted to signed,then a>b. What's the correct coversion
(what is the compiler supposed to do?)

The usual aritmentic conersions are performd (5.1/9) which means the
integral promotions (4.5) are performed which means both a and b are
converted to int values of 3 and 255 respectively. The value of a<b
therefore is true.

 

[Ben Hutchings]

on Thu, 10 Jul 2003 23:10:49 +0000 (UTC),


No, it's a signed integer converted to an unsigned integer. And it's a
value that the unsigned target cannot represent, so the value of b is
actually implementation-defined.

<snip>

No, this is well-defined (standard 4.7p2). It's the reverse that is
implementation-defined.

 

[Ioannis Vranos]

Remember that char, signed char and unsigned char are three disticnt
types.

char is implemented either as signed char or as unsigned char.



FWIW, if I'm using the value in an arithmetic context, then I

always write either signed char or unsigned char. If I'm using it to
represent text elements, then I write char. And I probably wouldn't
write:

char a = 3;

I'd write

char a = '\003';

It's a personal issue. I am thinking in integral form, so i would write 3 if
i had not a specific character in mind.

In fact, unsigned char may be promoted to unsigned int (depending on the
environment).

If the involved values fit in int, they get promoted to int. It's in the
standard.

I had trouble parsing that - I assume you meant

"So in summary, either a signed char or unsigned char gets converted to
int."
?

"So in summary the variable a, either it is signed char or unsigned char
gets converted to int (in real world scenarios where sizeof(int)>1)".






--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

 

[James Kanze]

(e-mail address removed) ("Ioannis Vranos") writes:

|>
|> > Well actually I was using chars only to save my mind from
|> > calculating it all out. Let's try again.

|> > I also intended this code to be used on a two's complement
|> > machine.

Which doesn't change anything here.

|> > Use this:

|> > signed int a = 3;
|> > unsigned int b = -1; /* thus being the highest number represented by
|> > unsigned int*/
|> > if (b<a)

|> > Now. If b were converted to a signed integer, b<a would be -1<3
|> > == true. If a were converted to an unsigned integer, we would
|> > get 65535 < 3 == false (in 16-bit environment). Which
|> > representation does it follow. Does it proceed like the char
|> > conversion, where it is converted to a signed int? Is this at
|> > all standardized, or does the compiler get to pick?

|> The C++ standard says:
|>
|> [conv.prom] 4.5 Integral promotions

Wrong section. There are no promotions here.

|> 1 An rvalue of type char, signed char, unsigned char, short int,
|> or unsigned short int can be converted to an rvalue of type int if
|> int can represent all the values of the source type; otherwise,
|> the source rvalue can be converted to an rvalue of type unsigned
|> int.

[...]

|> The (1) is your case.

Not at all. That paragraph only applies if the type is char, signed
char, unsigned char, short int or unsigned short int. There are none
of those here.

|> The answer is that everything is promoted to unsigned int and you
|> must get a compiler warning about comparing signed with unsigned
|> values.

Right answer, wrong reason. See 5/9 -- it gives the complete list of
conversions (call the usual arithmetic conversions) which apply to
binary operators. In particular, the last point "Otherwise, if either
operand is unsigned, the other shall be converted to unsigned."

|> Try to compile and see.

That's not always a valid solution. If he were comparing a long and
an unsigned int, for example, the conversions used will depend on the
implementation.

 

[James Kanze]

(e-mail address removed) (Francis Glassborow) writes:

|> In article <%jjPa.31$zd4.2@lakeread02>, MiniDisc_2k2
|> >Okay, here's a question about the standard. What does it say about
|> >unsigned/signed mismatches in a comparison statement:

|> >char a = 3;
|> >unsigned char b = 255;
|> >if (a<b)

|> >Now what's the real answer here? If a is converted to unsigned,
|> >then b>a. But, if b is converted to signed,then a>b. What's the
|> >correct coversion (what is the compiler supposed to do?)

|> No, the normal integral promotions are applied first Which only
|> becomes mildly interesting on systems where all integral types are
|> the same size.

But on such systems, 255 is within the range of char, so the problem
isn't interesting either. (For that matter, as formulated, it isn't
interesting on a system with 9 bit bytes either.)

 

[Andy Sawyer]

on Sat, 12 Jul 2003 00:16:53 +0000 (UTC),

char is implemented either as signed char or as unsigned char.

Please cite your reference. I suggest you read 3.9.1p1, which says in part:

,----
| Plain char, signed char, and unsigned char are three distinct types.
`----

It's in the standard (almost word-for-word - I omitted "plain").

If the involved values fit in int, they get promoted to int. It's in the
standard.

Again, cite your reference. I suggest you read 4.5p1, which says:

,----
| An rvalue of type char, signed char, unsigned char, short int, or
| unsigned short int can be converted to an rvalue of type int if int can
| represent all the values of the source type; otherwise, the source
| rvalue can be converted to an rvalue of type unsigned int.
`----

It's in the standard.

Note the "if int can represent *ALL* values of the source type". (my
emphasis). I suspect you're thinking of integral _conversions_, which
(in this context) happen after promotions - see 5p9. It's in the standard.

"So in summary the variable a, either it is signed char or unsigned char
gets converted to int

Not necessarily - it's in the standard.

(in real world scenarios where sizeof(int)>1)".

There are real world scenarios where sizeof(int)==sizeof(char). Neither
your being unfamilair with them, nor the fact that they are less common
than those where sizeof(int)>sizeof(char) does not in any way disprove
their existence.

Regards,
Andy S.

 

[Andrey Tarasevich]

char is implemented either as signed char or as unsigned char.
...

Well, 'long int' can also be internally "implemented" as 'int' (which is
the case in many implementations). Nevertheless, 'long int' and 'int'
are two distinct types. The same applies to 'char', 'signed char' and
'unsigned char'.