Re: Best practice in C to support 64-bit or 32-bit address length with same source file ?

[Ken Raeburn <raeburn raeburn org>]

On May 4, 2008, at 12:38, Davis Johnson wrote:
> In my experience NULL has usually been defined as somthing like  
> ((void *)0). In any event it should be defined to be somthing that  
> is safe to use as a pointer. It probably shouldn't be defined as  
> just 0 unless int and pointers are, in fact, interchangable on that  
> archetecture. Don't rule out the possibility of broken archetectures.

Usually, perhaps, but by no means always.  Solaris, for example, uses  
0.  The C spec basically guarantees that it'll be converted to the  
right pointer type when the context demands.  Variadic function calls  
and a few other cases (e.g., sizeof(NULL)) don't force any specific  
pointer type on it, and thus may leave it an integral type.

> K&R C didn't have a void type so older programs (and  
> implementations) may not use (or have) it.

Really old programs, perhaps.  Any implementation that old should just  
be thrown out -- the use of void predates the 1989 version of the C  
standard.  It probably wouldn't even be able to bootstrap a modern  
version of GCC.

> Casting to the right pointer type is somthing I skimp on because  
> everything I've written code for for a long time has had the same  
> pointer representation for anything. That is lazy, however. You are  
> correct that arguments to variadic functions should be correctly cast.

There are a lot of things "usually" done that aren't good ideas to  
rely on.  NULL automagically being the right pointer type for variadic  
functions, all pointers having the same representation, memset(,0,)  
giving you null pointers and zero floating point values, signed  
arithmetic always wrapping, etc.  You can write fairly "portable" code  
that makes these assumptions and works... until you encounter a  
machine or compiler where it doesn't.

I used to write code for a machine that had multiple pointer  
representations, for a little while.  (It didn't actually have a C  
environment at the time, though.)  It also had a segmented  
architecture, and a standardized null pointer representation that  
wasn't all-bits-zero.  So I'm probably a bit more picky about these  
things than many C/Linux programmers starting out today. :)  Still, I  
think it's better to teach them to be careful about machines they  
might not ever encounter, rather than too sloppy for machines they  
very well might....

Ken