nanogui: Use of "unsigned long" for 32-bit quantities
Subject:
Re: [nanogui] Use of "unsigned long" for 32-bit quantities
From:
"Paul Bartholomew" ####@####.####
Date:
1 Jul 2005 06:24:31 +0100
Message-Id: <BAY108-F37D531334F5C642F5E1AB1EFE20@phx.gbl>
>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.
Of course. As I said:
>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.
The key phrase being "when the code really means: 32bits or 16 bits". I do
NOT mean that someone should use something like "sed" and replace every
single "unsigned long" with "uint32". It needs to be done with knowledge of
the context of the code. That's why I said it would probably be better for
someone more familiar with the code to do it (rather than me).
>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.
Again, we wouldn't be changing 'pointers' to 'uint32' - only 'unsigned
longs' that are *meant to be* '32bit integer'.
But, "determining that your font doesn't look right" doesn't seem the right
way to do it either. There could be tons of cases of mis-used types where
(for example) memory is being corrupted (on certain platforms, like where
"unsigned long" != 32bits). I ran into the font issue immediately,
*because* it's "visible". It doesn't mean that other parts of the code
aren't doing the wrong thing on my platform - just because there wasn't an
immediatly "visible" problem on the screen.
So, to re-state (and perhaps change things to be a bit less "scary"): I
suggest a global header file with these special typedefs. If you are
working on a module that needs to address things as specific bit sizes (like
32bits), then change things like "unsigned long" to "uint32". Because I've
spent some time in "font_pcf.c", I'd feel comfortable doing it there. Other
people that are comfortable with other modules could (if they feel inclined
to make the code more 'portable') modify those modules where applicable.
That's my suggestion. Overall, I'm pleasantly surprised at how 'portable'
Microwindows/Nano-X have been, but there still seem to be some portability
issues (like this problem, and the 'endian' issues I've also run into). I
assume it's a goal of the project to be very portable - this can only help,
IMO.
Regards,
- Paul B.
