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.
Message
RE: [lpc2000] unsigned long versus unsigned int on ARM7
2005-11-09 by Paul Curtis
Attachments
- No local attachments were found for this message.