Defining Portable (Was: Invalid pointer addresses)

[Richard Harter]

In article <1988Sep16.170408.16304 at utzoo.uucp> henry at utzoo.uucp (Henry Spencer) writes:
>In article <10595 at ulysses.homer.nj.att.com> jss at hector.UUCP (Jerry Schwarz) writes:
>>The above illustrates an unfortunate shift that is occurring in the
>>use of the phrase "portable code".  When I use that phrase I mean
>>that IN PRACTICE the code can be run on a large variety of systems.
>>It is not a binary attribute...
>>Doug (and others) appear to be using "portable" to mean that the code
>>whose behavior is guaranteed by the ANSI standard...

>Yes, we do.  The reason for this is that it's not that hard to do.  A
>serious commitment to portability should imply this level of effort;
>anything much less is sheer laziness.  It does require a bit of work,
>and avoidance of certain items of "VAX chauvinism" like assuming a
>big linear address space or 32-bit ints.  Big deal.

Having dealt (the hard way) with portability issues, I have to agree
that portability is, in general, not a binary issue.  A program is
fully portable if you can port it to all machines having a C compiler
without altering the code.  It is *very* difficult to do this in
programs of any size.  There are several classes of problems.  There are
C compilers that are archaic, idiosyncratic, or just plain broken.
A portable program works on these compilers.  [The reply, "my program
is portable, it's the compiler's fault", doesn't cut the mustard.  If
you have to port you are going to have to work with what you've got,
not with what you think you should have.]  There are sundry implementations
of the standard (:-)) library routines.  There are architectural 
considerations, and so on.

Henry is quite right to point to the assorted slop that comes from
assuming that anything that works on the machine I am using now is
OK to use anywhere and decry it.  However in practice portability is
relative to a class of machines and compilers.  Maybe some day you will
be able to write real portable code that works on all machines, because
there is a standard that everyone follows.  In the mean time the rule
is that you define the portability assumptions that you are going to
work within, and you know what restrictions those assumptions imply.

*note: In a VMS C port recently we got bitten on the monocase externals
gotcha.  A nice tool to have would be one that reports all potential
identifier problems.

-- 

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