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

[fjh@mundook.cs.mu.OZ.AU (Fergus Henderson)]

seebs@solutions.solon.com (Peter Seebach) writes:

>Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote:
>>It is clear that (a) such code is broken and (b) the fact that
>>it has undefined behaviour causes portability problems.
>>What you said and what Robert Dewar said are not contradictory.
>
>Yes, they are.  There is no portability problem in the C language, or
>the behavior of read().  It is not a portability program for a mistake
>to behave randomly or differently on different machines.

No, it is definitely a portability problem if a mistake behaves
differently on different machines.  It is a portability problem,
because almost every non-trivial program contains mistakes, and so
if a mistake can behave differently on different machines, that means
that almost every non-trivial program will behave differently on
different machines.  If behaving differently on different machines
in ways not intended by the programmer isn't a portability problem,
then I don't know what is!

>>... the undefined behaviour of read() and printf() both cause portability
>>problems.
>
>No, they define the boundaries of a language; things beyond that boundary
>are *supposed* to be undefined.  Since no program in the C language ever
>runs into that behavior of a C implementation, it is not a portability
>problem.
...
>>Ha!  Obviously you have never tried porting any serious C programs.
>
>Any program which does that is not a C program; it has left the bounds of
>defined behavior.

If you adopt that definition, then what I said -- that obviously
you have never tried porting any serious C programs -- is still true,
since no serious programs are written in 100% strictly conforming ANSI C.

However, such specious definitions belong in an ivory tower, not in the
real world.  You're trying to define the problem away, but the problem
is a very real problem which has very real costs.

>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.

No, the portability problem is the different behaviour of the program,
when run on different systems.  It does not "lie in" the program -- it
makes little sense to speak of behaviour "lying in" a program.  The
behaviour is not something that has a single cause -- rather, it has a
multitude of causes, some direct, and some indirect.  The problem is
caused by the program AND by the implementation AND by the language spec.

Of course, you can't really assign blame to any of these abstract
entities; blame, if it is to be assigned, must be assigned to the
people responsible.  But you can't blame any of the people involved too
much.  You can't really blame the language designers or language
committee much; after all, they were just doing their best to specify
the language in a way which allowed implementations some flexibility.
You can't really blame the implementors, even though they may have
known that defining things the way they did might lead to portability
problems; after all, they were only following the spec!  And you can't
really blame the programmers too much for making the occasional
mistake; after all, they are only human!!

>No point blaming the language for incompetent or foolish programmers.

Every programmer has done something incompetent or foolish at some time.

Programming language design should take this, amoung other things,
into account.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.