Further to my previous comment:

What the compiler is doing actually makes sense.

When attempting to find a common type to convert to when dealing with two
types, if the value that can be held by one type can be held by the other,
the superset type will be used.

In this case it is not possible as the types can hold incompatible values. =
A
signed int has values that an unsigned int cannot hold, and vice versa.

There are really two choices for the compiler: promote both to a larger typ=
e
that can hold both values or pick one based on some rule.

Promotion does not work well in this case because there is nothing obvious
to promote an int to. Even if these were shorts, promoting them to a signed
int is not guaranteed to work because the sizes of shorts and ints could
actually be the same (it is implementation defined).

This leaves the choice of converting one operand to the other type based on
a somewhat arbitrary criterion. The rule is that it uses the type that can
hold a larger value, hence unsigned int.

It all makes sense when you think about it carefully.

-----Original Message-----
From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Behalf Of
PICLIST
Sent: Friday, May 02, 2014 10:41 PM
To: 'Microcontroller discussion list - Public.'
Subject: RE: [OT] Why on earth??!?

The C standard is unambiguous about what should happen in this case and the
compilers are operating as required by the standard (see section 6.3.1.8).
Except for where the C standard leave some things as an implementation
choice, the standard is usually very clear. I don't think it is clear in
this case, but it is unambiguous.

The trick of course, is to fully understand the standard when you are
programming in C. The other trick is to stay away from things that are
somewhat more subtly defined (for instance operations mixing signed and
unsigned types), but that is what the original posted didn't want to hear.

I think one of the worst things the C standard does is leave the size of
many standard types i.e. int, as implementation defined.=20

See:=20

http://c0x.coding-guidelines.com/6.3.1.8.html

-----Original Message-----
From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Behalf Of
John Gardner
Sent: Friday, May 02, 2014 6:00 PM
To: Microcontroller discussion list - Public.
Subject: Re: [OT] Why on earth??!?

That's the trouble with HLL - The good news is - You don't

have to keep track of what the compiler is doing (You hope.)

The bad news - What the compiler actually does sometimes

endows you with "experience"...



 Eppur, si muove...
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/chang=
e
your membership options at http://mailman.mit.edu/mailman/listinfo/piclist

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/chang=
e
your membership options at http://mailman.mit.edu/mailman/listinfo/piclist

--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.