Machines for testing portability (was Re: "Numerical Recipes in C" is nonportable code)

Marty Fouts fouts at lemming.nas.nasa.gov.nas.nasa.gov
Wed Aug 31 01:56:45 AEST 1988


I have the (mis)fortune of having access to a wide range of machines,
and find that portability issues fall into about four catagories: (for
me, your milage may vary)

1) floating header files  (where is struct mumble defined, where does
   header file bletch.h live, etc.)

2) library differences (is it in libc, or libm, is it strchr or
   rindex, does it exist or do I have to carry my own version along. . .)

3) Implementation problems (working around bugs in the system. . .)

4) Architecture dependencies due to language design or implementation
   decisions left to the implementer.  (it worked on my brand x, but
   after I tried it on brand y, I went back and read K&R and sure
   enough its not legal. . .)

The rude fact is that the first three can't be covered by any small
set of machines, although a fairly good aproximation can be made by
trying a System V machine, a BSD machine, an MS-DOS machine, and a non-
un*x machine. (VAX/VMS, Apollo)

As far as the fourth goes, I have been bitten by the following
collection of dumb assumptions:

1) byte ordering
2) word size
3) "all pointers are == char *"
4) calling stack implementation
5) assuming a linear address space without holes

My collection of machines which ring out these problems is fairly
small, but probably not widely accessable.  I find that I can get by
with only three machines to cover all of the dumb assumptions: A Vax
11/780, a Cray 2, and an Silicon Graphics Iris 4D.  The Cray system
seriously strains dumb assumptions in 1-3 and 5, and the Iris gets 4.

Without the 2, a much larger collection of machines would be needed,
but I suspect that a lot could be accomplished with an IBM PC and a
SUN-3 as an alternative.

Anyway, I don't assume that code I've written is reasonably portable,
until it compiles and appears to work on 16, 32 and 64 bit machines of
varying byte order, memory model and calling stack implementation, and
then I only assume that it is reasonably portable and that I've blown
it for the next class of machines I'm going to see.  This is a very
healthy paranoia to develop.

Marty

+-+-+-+     I don't know who I am, why should you?     +-+-+-+
   |        fouts at lemming.nas.nasa.gov                    |
   |        ...!ames!orville!fouts                        |
   |        Never attribute to malice what can be         |
+-+-+-+     explained by incompetence.                 +-+-+-+



More information about the Comp.lang.c mailing list