nanogui: Use of "unsigned long" for 32-bit quantities


Previous by date: 9 Jul 2005 15:46:55 +0100 Re: [patch] added const qualifier in nano-X API, Greg Haerr
Next by date: 9 Jul 2005 15:46:55 +0100 Re: Elliptical Regions, Greg Haerr
Previous in thread: 9 Jul 2005 15:46:55 +0100 Re: Use of "unsigned long" for 32-bit quantities, Aaron J. Grier
Next in thread:

Subject: Re: [nanogui] Use of "unsigned long" for 32-bit quantities
From: "Greg Haerr" ####@####.####
Date: 9 Jul 2005 15:46:55 +0100
Message-Id: <4c6f01c58494$d7b385a0$6401a8c0@winXP>

: > 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.

I tend to agree with Jordan on this.  We can get into trouble
when we start using uint32's without completely understanding
the full ramifications.  Having said that, Microwindows is
basically too big these days to run on 16 bit systems.

: 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,

Agreed.  I'm very big on portability and have thought about
this constantly during Microwindows development.  (see my
comments about const earlier).  One of the reasons things
work well now is that I've tried to use simple "int" and "long"
declarations, and only force sizes in image decoding.
This has worked well, because the move from 16 to 32 bit
compilers has been very well thought out.  It seems Paul's
issues are the result of moving to 64 bit systems, and I have
to admit, I'd imagined that unsigned longs would be 32 bits,
so there's likely places this needs to change.


I'd suggest first getting advice on where the problems are in the
engine and driver layers, and then afterwards deciding on the
best approach to more portability.

We also need to find some folks to volunteer testing big-endian;
I don't have such a system to test with, which is why the
big-endian bugs are there in the first place.

Regards,

Greg


Previous by date: 9 Jul 2005 15:46:55 +0100 Re: [patch] added const qualifier in nano-X API, Greg Haerr
Next by date: 9 Jul 2005 15:46:55 +0100 Re: Elliptical Regions, Greg Haerr
Previous in thread: 9 Jul 2005 15:46:55 +0100 Re: Use of "unsigned long" for 32-bit quantities, Aaron J. Grier
Next in thread:


Powered by ezmlm-browse 0.20.