Defining Portable (Was: Invalid pointer addresses)

[Doug Gwyn]

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:
->Doug (and others) appear to be using "portable" to mean that the code
->whose behavior is guaranteed by the ANSI standard...
-We (at least, I think I speak for Doug and others as well as myself)
-are willing to use "portable" as a non-boolean attribute, e.g. to talk
-about "levels of portability", but when we use it as a boolean, e.g.
-"this program is portable", that's what we mean.  This is a reasonable
-and proper usage.

Actually, I'll usually say "standard conforming" when that is what I intend.
To me, portable C programming involves considerably more than merely not
violating language specifications; it also means not relying on specific
aspects of the implementation that are not nailed down by the spec.  (There
are many intentionally "implementation defined" areas of the C language.)

If one gets in the habit of not relying on system-specific assumptions,
it becomes progressively less of an issue.  Perhaps a couple of times a
year I'll have to make a deliberate decision as to whether to rely on
some non-portable assumption (which should ALWAYS be clearly flagged as
such), for example relying on the ASCII character codes when converting
numeric text strings to internal binary.  The rest of the time I don't
even need to consider whether it might be worth doing that; it's not
appreciably more trouble to use a fully portable method.

I like to think my applications will run without change on systems from
Apple IIs to Cray-2s (all of which we have around here or at home).  Of
course usually prevents full attainment of this ideal, but there is no
good excuse for not trying.