Portable code (was compiler differences)

[Richard Harter]

In article <1124 at silver.bacs.indiana.edu> backstro at silver.UUCP (Dave White) writes:
>In article <22314ad9 at ralf.home> Ralf.Brown at B.GP.CS.CMU.EDU writes:
>>In article <1106 at silver.bacs.indiana.edu>, backstro at silver.bacs.indiana.edu
>>(Dave White) writes:
>>}When will [PC C compiler vendors] realize that some of us really want
>>}the option of using 32-bit ints to port Unix-born code?  
>>
>>#define int long
>>
>>Need I say more?
>It isn't that simple. Your suggestion would ensure that the
>compiler thought the code I was compiling saw ints and longs
>the same way, but this would not be the case with the compiler's
>run-time library, which would need to be recompiled and debugged.
>alloc and friends, for example, take int-sized arguments in my machine!

The idea is right, but insufficient.  One way to do things is thusly:

Replace all declaration types int, long, char, float, double by INT,
LONG, CHAR, FLOAT, DOUBLE, with the obvious definitions in your home
system.

Define, for each library routine used, typdefs for each argument,
and for the return.  For each library routine call, cast the argument(s).

All this good stuff goes into an include file that all files include.
In the target machine the type definitions change, according to the
target machine.  This can be taken care of conveniently by ifdef's.

As a matter of practice, it is more better if each library routine
used appears explicitly only once in your code, e.g. your standard
include file contains definitions for each library routine in terms
of itself.  [This doesn't work for printf and family which have
variable number of arguments.]

This resolves the first level of portability;  everything is casted
to the right size.  It does not help you if your home machine has
32 bit ints, and you actually have quantities which are greater than
16 bits in size which you pass to library routines.  It also doesn't
help if the calling sequences in the target machine use different
calling sequences.

You can do this conversion as a quasi-mechanical process; i.e. you
do greps on the original code to generate lists of files to be changed,
and edit scripts to implement the changes.  It's only quasi-mechanical
because you have to do hand checks on the results.

-- 

In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
	Richard Harter, SMDS  Inc.