Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

RE: [lpc2000] unsigned long versus unsigned int on ARM7

2005-11-09 by Paul Curtis

Hi,

> I have noticed that many folks are using 'unsigned long' for 32 bit 
> entities and I got to wondering if I am doing things wrong (again!)
> 
> Looking at limits.h I come up with:
> 
> unsigned char -> 8 bits
> unsigned short int -> 16 bits
> unsigned int -> 32 bits
> unsigned long -> 32 bits or 64 bits depending on architecture
> 
> Assuming that I care that my code is portable, what is the 
> considered opinion on unsigned int versus unsigned long for 32 bit 
> entities?

No difference on many 32-bit compilers.

> I followed a thread on the Internet that stated that the latest 
> standard required that the rank of each type (where rank wasn't 
> clearly defined in the minds of the participants) had to be greater 
> than its predecessor, not greater than or equal to.  If that is 
> indeed the standard, the rank of unsigned long must be greater than 
> unsigned int and thus reserved for 64 bit kinds of things.

That is wrong.  The C standard requires that the following equality and
inequalities hold:

1 = sizeof(char)

sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) <=
sizeof(long long)

It is quite possible to produce a standard-conforming compiler where all
types are 64 bits in size.  In fact, the Texas Instruments 320C40
compiler had a 32-bit char, short, int, and long.  Yes, it was not a
byte-oriented machine and much trouble with byte-oriented protocols
ensued.

> Now, I realize my stuff is never going to move to a SPARC but it 
> would be nice to get it right.
> 
> I have been trying to avoid the use of macros such as ULONG just to 
> be pedantic, I suppose.
> 
> So, what is everyone else doing?

Try investigating <stdint.h> if your compiler has it.

-- Paul.

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.