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

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

Kazimir says

"Dewar: in the absence of clarity in a standard, as an implementor, follow the
pack. Look at what most implementations do, and stick to the unwritten
standards of the community."

That of course completely misunderstands my position and Kazimir's failure
to undertand the central issue here is a great illustration of my central
point. In fact I could not have asked for anyone to make the point 
more clearly.

I brought up this thread not as a discussion of proper programming
practices, but of the importance of specs, and to give an example
of portability problems caused by inaccurate specs.

Kazimir's view is "so what if the specs are vague, never mind, if people
are "rational" or follow "unwritten rules", then it probably won't matter
much.

The trouble is that it absolutely *does* matter, and it matters much!
If programmers continue to follow Kazimir's casual attitude towards
specs, then we continue to get libraries, and, as we see in the case
of POSIX, even standards, that are unacceptably vague.

I am not asking for formal specifications, although with library
routines like this it would not be too hard, and would definitely
be useful, but I think people need to have more formal training
in semantics, so that they understand the critical issue of
clear specifications.

The bravado attitude of Kazimir and Peter -- "people shouldn't make
errors, if they do they get what they deserve", or "people should
think clearly, real programmers don't need specs [to be fair that
is Kazimir and not Peter]" is actually often more of a menace
than incompetence. I have often seen big programs get into horrible
trouble because a really clever programmer thought that rigorous
engineering could be replaced by programming brilliance.

As I have said many times, the details of the read issue are not that
important. It is simply a case where different implementatoins have
subtly different specs, and consquently a program that is semantically
correct in one implmentation is wrong in another. The only cure to this
problem is clear specification at an abstract, implementation-independent
level. People who think that they can overcome the lack of such clear
abstract specifications by guessing what is rational or reasonable
are fooling themselves badly.