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

[Davis Johnson]

Jim McCarthy wrote:

> <><snip/>
> I'd appreciate any expert opinions and/or code fragment examples of 
> how best
> to implement this (given the myriad of possibilities a novice in my 
> position
> might come up with ...).
>
> Thanks,
>
> -- Jim

<snip/>

1) Treat pointers as pointers and ints as ints let the compiler sort it 
out -- to the extent possible.

2) Make sure you have proper function prototypes for all functions.

You get into problems when:
* The same field in a data structure is used for ints and pointers at 
different times.
* ints and pointers are passed on the stack and no (or incorect) 
function prototypes are used.
* doing home-rolled variable argument lists instead of the va_arg stuff
* having pointer values that pass thru ints because "they are the same 
thing".
* doing bit-level manipulation of pointers.

A great many evils are avoided by following the two rules stated above. 
Unfortunatly, some older programs from the days of restricted memory and 
K&R compilers break these rules and do all the bad things. Some newer 
ones do too.

Rule 1 includes using NULL for null pointer values and not 0. It also 
includes using %p to format pointer values. There are probably some 
other things I should add.

If you like, rule 2 can be thought of as a special, but easy to 
overlook, case of rule 1. It is arguably not necessary as long as the 
types of the arguments in all calls are exactly what the prototype calls 
for. Rule 2 makes it possible for the  compiler to  help  you keep your 
arguments straight.

Keep your nose clean and you won't have problems with new code you 
write. Its the old stuff that will give you fits.

I survived the transition from it being 16 bits to int being 32 bits. 
That included a lengthy period when both were common. Sort of like today.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/axp-list/attachments/20080503/8d0368e6/attachment.htm>