C integer promotions (was: Code packing)
M. Adam Davis email (remove spam text)
Herbert Graf wrote:
> That said, I am interested in the "integer promotion". What ARE the rules
> for promotion? I have been hit a couple times with promotion happening
> when I didn't think it would, and other times not happening when I
> thought it should have.
There are rules for promotion, but they can't be counted on as every
compiler implements them a little differently, and different
processors implement them differently. Further, few compilers
(especially in the PIC world) claim full ANSI compliance so even
though there are rules you have to check every single compiler that
you use, and then look to make sure that the command line options
aren't changing the rules on you.
Which is why EVERY single operation that involves different types
SHOULD be explicitly cast, and in the automotive industry (as in many
other high reliability industries) this is a requirement.
This is especially true if you expect the code to be portable or
reusable. Do you really want to debug your debounce routine every
time you try and use it on a new compiler or processor?
> What are common "gotchas" with regards to type promotion?
The older, more common ANSI C standard does not define a char as
signed or unsigned - your compiler is allowed to treat a char as
either signed or unsigned, and every good compiler has a seperate type
that means unsigned 8 bit or signed 8 bit.
This bites a lot of people who assume that it's one or the other, then
it gets promoted to an integer or unsigned integer (depending on the
compiler's view of char) and can have unintended effects based on
whether its sign extended or not.
Further, an integer may be (commonly) 16 bit or 32 bit (or even 64
bit) - this was left as an implementation detail to generically mean
the processor's native integer format. You might be surprised moving
a PC program (32 bit) to a limited processor and seeing your variables
roll over at 32,767.
> Since I'm not that familiar with the rules, I generally explicitly cast
> so that I don't have to worry about them, but now I'm curious! :)
This is the most reliable way to deal with it. In fact, automotive
companies (and many companies, I've found) don't even use the standard
names because it affects more than just the char. A types.h file is
used to typedefine every type for a particular compiler (using #ifdef
COMPILER type statements) so that, for instance, you'll see T_u8 for
unsigned 8 bit variables, T_s16 for unsigned 16 bits, T_bit for
TRUE/FALSE boolean (which usually goes to the processor's native int
for speed and to avoid bit packing) etc.
When a new compiler is used, the types.h file is updated to include
the correct mapping for types so the program is still portable.
It's also extremely handy when testing your software on the PC - you
can compile it in both Visual Studio and your micro's compiler and
know the types and casting will happen correctly.
If you're really interested in other C gotcha's, check out MISRA
online (often mis-pronounced misery - it's a pain to comply with most
of it). If I understand correctly a lot of these stem from the book
"C Traps and Pitfalls"
EARTH DAY 2008
Tuesday April 22
Save Money * Save Oil * Save Lives * Save the Planet
In reply to: <email@example.com>
See also: www.piclist.com/techref/language/index.htm?key=c
You must be a member of the
piclist mailing list
(not only a www.piclist.com member) to post to the