nanogui: Use of "unsigned long" for 32-bit quantities
Subject:
Use of "unsigned long" for 32-bit quantities
From:
"Paul Bartholomew" ####@####.####
Date:
30 Jun 2005 20:44:52 +0100
Message-Id: <BAY108-F38B10444E27EF545EBA6F8EFE30@phx.gbl>
I've noticed in some parts of microwindows/nano-X, "unsigned long" is used
to mean "unsigned 32-bit value".
On my platform's compiler, "unsigned long" is > 32 bits (I think it's 64
bits - I don't remember), so things in microwindows/nano-X 'break'. For
example, in "engine/font_pcf.c", in "pcf_createfont()" ,there's an "unsigned
long *ptr" that's used as a pointer into the bitmap data. "(xwidth + 1) /
2" is added to it, with the assumption that sizeof(unsigned long) is 4
bytes. When sizeof(unsigned long) is 8, all offsets into the bitmaps are
screwed-up.
I usually use "unsigned int" to mean 32-bit value, but I know that some
smaller embedded compilers use 16 bit integers (so, I assume that's the
reason "unsigned long" is used).
I suggest a global header file with 'generic' typedefs (like "uint16",
"uint32", etc), which can be customized based on your compiler. Then,
instead of using types like "unsigned long" and "unsigned int" throughout
the code (when the code really means: 32bits or 16 bits), use the new
"uint32/uint16" types.
Does this seem like a good idea? If so, how difficult would it be to get
done? (I know that I could do it, but others probable know the microwindows
code a lot better than I do, and could do it more quickly). If nobody else
volunteers, and nobody *objects*, I'll go ahead and make the changes.
I'd appreciate feedback.
Thanks,
- Paul Bartholomew
