Lpc2000

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? 
> 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
>