Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)

[dewar@cs.nyu.edu (Robert Dewar)]

Peter Seebach said

"Further, that behavior is a flat out bug; it is never correct, and the
portability problem lies in the program, not the language spec.  The
program needs to be fixed."

Gosh, I was a little concerned that when I wrote my "portable programs
are portable" note that it would be considered too obvious, but Peter
certainly is confused, so perhaps it is worth restating.

It is true of any language that a portable program is portable given:

  a portable program is one using only features of the language whose
  semantics is target independent.

  the implementations of the language on the machines involved are
  correct.

But this is quite useless in the discussion of portability problems. It
is indeed clear that Peter has not been involved in large porting 
efforts. His comments are reminiscent of an attitude that says "bugs
in programs are not a problem - don't put bugs in your programs".

In practice portability problems (i.e. problems in porting programs)
stem from several possible sources:

  o  Non-portable constructs introduced deliberately
  o  Non-portable constructs introduced accidentally
  o  Use of third party libraries etc, outside the language
  o  Incomplete or inaccurate implementations

In practice, porting large programs tends to run into problems of
each variety.

The language design is not exactly directly responsible in any of these
areas, but it is also not completely independent of them either.

Non-portable constructs introduced deliberately

  Some languages make it more necessary to do non-portabe programming
  than others, e.g. in C we cannot define integer types that have
  portable ranges, in Ada we can easily do so.

  Some languages allow extensions more freely. For example, most languages
  do not prohibit extensions in the standard -- the standard for COBOL for
  example (like most others) defines what the required feature set is and
  has nothing to say about programs outside the valid set. In the case of
  Ada, the standard requires rejection of any program NOT in the valid set.

Non-portble constructs introduced accidentally

  This is more subjective certainly, but here too language plays a part.
  For example both C and Ada allow the type model to be broken, C easily
  with a cast, Ada only with a big syntactic stink about unchecked
  conversion.

  Another area where this occurs is when specs are vague, the discussion
  about read is a good example (although of course not directly relevant
  since read is not a language feature). An example in C is the exact
  semantics of X++ in a multi-threaded environment (there are obviously
  two possible semantics, normally the same, but not in a threaded
  environment).

Use of third party libraries etc

  This can obviously be alleviated by including more such stuff in the
  language. Many people took the attitude that the original C language
  did not include I/O, but the ANSI standard clearly takes an opposite
  point of view and has incorporated many standard library routines.
  Similarly, Ada 95 differs from Ada 83 in the addition of a large
  standard library.

Incomplete or inaccurate implementations

  Small, simple languages are likely to fair better here. FOr example,
  other things being equal, one would expect a C implementation to more
  easily and consistently be a full implementation of its spec than an
  Ada 95 or C++ implementation. Of course th "other things being equal"
  here is important. External factors such as the quality of validation
  suites, and the precision of the relevant standard, may well have
  a significant influence.

But the bottom line here Peter is that we all know that in all languages
it is possible for a very careful defensive programmer who knows the
standard well, and who avoids likely trouble spots, can write portable
code, especially if no system-dependent mucking is involved. But this
has little to do with the practical issue of the world of portablity
problems.

I certainly agree that programmers who know the relevant standard are
in better shape. It amazes me to find out how few C programmers have
read the C standard (similar situations are true with Fortrn and
COBOL). Ada interestingly is different, typical professional Ada
programmers do have a copy of the Ada standard at hand, at least
for reference purposes.