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 Gromann, Klaus

The difference between long and int is machine dependend.

int depends from the processor type, that means int is 16 bit on a 16
bit machine and 32 bit on a 32 bit machine.
long is at least 32 bit.
short is allways 16 bit.

The best way to write portable code is to define your own datatypes.

i.e. for a 32 bit architecture

#define u8 unsigned char
#define u16 unsigned short
#define u32 unsigned int

and so on. 

If you change the architecture you only have to change the
"datatypes.h"-File.


regards
Klaus

-----Original Message-----
From: lpc2000@yahoogroups.com [mailto:lpc2000@...m] On Behalf
Of rtstofer
Sent: Wednesday, November 09, 2005 5:03 PM
To: lpc2000@yahoogroups.com
Subject: [lpc2000] unsigned long versus unsigned int on ARM7


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?

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.

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?

Richard









 
Yahoo! Groups Links

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.