nanogui: Use of "unsigned long" for 32-bit quantities
Subject:
AW: [nanogui] Use of "unsigned long" for 32-bit quantities
From:
"Alexander Stohr" ####@####.####
Date:
1 Jul 2005 09:26:36 +0100
Message-Id: <000d01c57e16$80127240$9b01a8c0@starlightpc>
Alexander Neundorf wrote:
> On Thursday 30 June 2005 21:44, Paul Bartholomew wrote:
> ...
> > 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.
>
> Sounds good, IMHO this would be the right approach.
GCC and many other compilers do support this:
#include <stdbool.h>
#include <stdint.h>
bool x = true, y = false;
uint8_t a;
uint16_t b;
uint32_t c;
uint64_t d;
int8_t e;
int16_t f;
int32_t g;
int64_t h;
this is a widespread and standarized C convention.
platforms that dont support these convention
wont take much user effort for the missing header.
for the sake of pointers, as user and system interpretation
might be different depending on misc factors like given flags,
the most generic approch is this:
void some_api_function (void *buffer, int flags);
this saves the user a bunch of typecasts
and enforces the system coder (unless the compiler is crap)
to explicitely apply a typcast on the buffer for the desired
data width which will impact any sort of pointer increment.
entry points with a fixed data width should not need the void-style.
-Alex.
