nanogui: Use of "unsigned long" for 32-bit quantities
Subject:
Re: [nanogui] Use of "unsigned long" for 32-bit quantities
From:
Jordan Crouse ####@####.####
Date:
1 Jul 2005 05:57:00 +0100
Message-Id: <42C4CD08.2040606@cosmicpenguin.net>
> 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.
You need to be extremely careful - I cannot emphasize that enough.
Remember that a good chunk of the 'unsigned longs' you find in the
Microwindows code are true pointers, and should be kept in the native
long format of the processor. Really, the only places where you would
specifically need a 32 bit type would be in the image and font decoding
sections, and a little bit in the drawing code where we probably make
some silly assumptions about the size of a buffer. The rest of the code
is pretty much designed only to work with itself on the target system
anyway. I think it would be far more damaging to have to figure out
why a pointer that was turned into a uint32 by accident deep in the
engine suddenly doesn't work on an amd64 machine then determining that
your font doesn't look right because of a misplaced unsigned long in the
PCF engine.
If it was me, I would skip the global header files, and just use the
common char/short/int designators for 8/16/32 and long for native
pointers, but then again, I only use gcc and I'm lazy like that. I
guess that <sys/types.h> can help me out in a pinch, but I'll leave it
to the rest of the group if a wholesale substitution of of
char/short/int types is in order.
Jordan
