That's why it's a good idea to define your types based on sizes: S8 -> signed 8-bit U8 -> unsigned 8-bit S16 -> signed 16-bit U16 -> unsigned 16-bit etc. This way you can define these in one place, base other types (structs, ...) and objects off of these, and throughout your code you know what you're getting. On 11/9/05, rtstofer <rstofer@...> wrote: > > 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 > > -- ---------------------------------------------------------- Jim Parziale Email: nuncio.bitis@... Malden, MA ---------------------------------------------------------- [Non-text portions of this message have been removed]
Message
Re: [lpc2000] unsigned long versus unsigned int on ARM7
2005-11-09 by Jim Parziale
Attachments
- No local attachments were found for this message.