From a standards point of view the only thing that can be guaranteed
for the normal basic ordinal types is this:
In section 6.1.2.5 the Standard states, "There are four signed
integer types, designated as signed char, short int, int, and long
int." ... "In the list of signed integer types above, the range of
values of each type is a subrange of the values of the next type in
the list."
In other words,
sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)
The standards make no guarantee of how big any of those actually is,
only that the sizes adhere to that. Technically all basic ordinal
types can be the same size, depending on the native type of the
processor. It's only by convention that most compilers limit char
to 8-bit, short to 16-bit, and "int" is fairly universally used
as "machine-type word in length". The alignment is also left up to
the discretion of the compiler. It may declare a char to be 8-bit,
but always align it on 32-bit boundaries, meaning that it could
actually be used as a 32-bit number (in some cases). printf is a
bad example of this. I see people all over the place always use %i
to display a number. Again, works great on 32-bit with 32-bit
alignment, but when ported to a different platform things start to
screw up.
Although it's a great idea to use C99 for "standard" size-defined
ordinals when you need them, keep in mind that they should only be
used when you must be sure of the size of your variable.
If you decide to write everything with uint32_t or uint16_t, keep in
mind that it will not execute as efficiently on machines that are
not native to that type. I.e. if you want to use a loop counter,
then just use an int or unsigned int, which "almost" guarantees that
the compiler will choose the most efficient type for the machine.
I've seen code where people insist on using uint32_t everywhere,
which works great on 32-bit machines, but when compiled for our
lovely 8051s the code runs like a total hog (not to mention using a
lot more memory that necessary). That's why I usually have 2 sets
of defines, one for specific variable lengths, one for "minimum
lengths". For example, like this:
#ifdef __8051__
#define uint8 unsigned char
#define uint16 unsigned short
#define uint32 unsigned long
#define mint8 unsigned char
#define mint16 unsigned int
#define mint32 unsigned long
#elif defined (__ARM7__)
#define uint8 unsigned char
#define uint16 unsigned short
#define uint32 unsigned long
#define mint8 unsigned int
#define mint16 unsigned int
#deifne mint32 unsigned int
#elif ...
(etc)
In other words
#define mint8 <at least 8-bit in length>
#define mint16 <at least 16-bit in length>
#define mint32 <at least 32-bit in length>
#define uint8 <exactly 8-bits in length>
#define uint16 <exactly 16-bits in length>
#define uint32 <exactly 32-bits in length>
This way I can be guaranteed that if I need to use a machine-type-
efficient counter that only needs to go between 0 and 50 then I use
an mint8. If I need a number that must be 32-bit, I use a uint32.
-- Sean
--- In lpc2000@yahoogroups.com, "Ake Hedman, eurosource" <akhe@b...>
wrote:
>
> David Hawkins wrote:
>
> > I use <stdint.h> to get the C99 types; int32_t, uint32_t, etc.
> > If the compiler doesn't have a stdint.h, then write one.
> > There are already too many versions of code with s32, S32,
INT32, ...
> > definitions out there, I figure go with the C99 names, even
> > if your compiler is not C99 compliant.
> >
> > Dave
>
>
> This is a *very* good suggestion. During the years I have used
many
> different constructs but as you write it is probably time now to
go for
> the C99 types once for all. Is there a place where they all are
listed?
Show quoted textHide quoted text
> I have never come across a stdint.h file yet.... ;-)
>
> Cheers
> /Ake
>
> --
> ---
> Ake Hedman (YAP - Yet Another Programmer)
> eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
> Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
> Company home: http://www.eurosource.se
> Kryddor/Te/Kaffe: http://www.brattberg.com
> Personal homepage: http://www.eurosource.se/akhe
> Automated home: http://www.vscp.org
>