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 Jim Parziale

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]

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.