On 07/03/2012 02:29 PM, Jochen Kunz wrote:
On every
platform I work on, and indeed every platform I've
*ever* worked on, unsigned short has been 16 bits, and unsigned int has
been 32. That includes the 8-bitters as well.
No. avr-gcc uses 16 bits / 2 bytes
for int / unsigned int.
I am looking at this very moment to a LCD connected to a ATmega168 that
printed sizeof( unsigned int) on said LCD.
I just went and looked, and I must apologize, you are absolutely
correct! I don't know what I was thinking when I mentioned AVR the
other day. I'm hip-deep in firmware and it's hot in here; that's my excuse.
However, and I maintain that this is the more salient point, the code
still works. ;) But see below.
Your confusion about sizeof( int) is the exact reason
why uint32_t and
its friends where introduced with C99.
I've still found no use at all for them.
Being typedefs, as we all know, they simply provide "aliases" for
standard C data types. It is no substitute for knowing the architecture
and the compiler you're using. When moving code back and forth, it
automates changing the data types around in a nice transparent way,
which is USUALLY a good idea. I tend to shy away from things that
automate away the control I have over what's going on.
Now, typedefs in general, I adore. I use them all over the place,
usually when creating aggregate data types like structs and unions. I
don't, however, use them as simple one-to-one aliases for non-aggregate
data types, regardless of what the guys on the C99 team tell me has
suddenly become an indispensable practice.
Regarding uint32_t and its friends: They are in the
C99 standard.
(inttypes.h) I use them all over the place. Especially on AVRs. I wrote
C code that I compiled without change on an AVR and on a PeeCee running
NetBSD/i386. I used (u)int(16|32)_t all over there to avoid the
sizeof( int) missmatch. This was important, as I did some fixed piont
arthmetic.
I can certainly see how it'd be important for that, in your scenario.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA