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

[scs@eskimo.com (Steve Summit)]

[followups trimmed, and should probably be trimmed further]

In article <dewar.828987544@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes:
> Lots of code is portable and broken, lots of code is (deliberately)
> non-portable and definitely not broken. Lots of code is carefully
> written to be portable, but runs into bugs in supposedly conforming
> implementations. Lots of code uses features that are useful, but for
> which no standard exists, and hence may run into portability problems.

All true.

> Equating portability with non-brokenness in general is naive. Even in
> an environment with a definite standard, writing portable code requires
> a lot more than just adhering to the letter of the standard!

Also true.  There's a lot of naivete in some of the knee-jerk
reactions about portability and conformance which tend to get
made here.  (I'm probably guilty of this myself.)

Perhaps the essence of the debate is getting lost in the shouting.
An example was brought up which, I gather, boils down to

	char buf[100];
	/* exactly 68 characters are known to be available on fd */
	read(fd, buf, 1000);

It wasn't clear whether this was being presented as a real-world
example of a portability problem, or as an example of code that
someone thinks should be written, should be portable in practice,
and should work.  (I sincerely hope it's the former, and Robert
Dewar has assured me that he, for one, is not defending it.)

Asserting that non-strictly-conforming programs are not C
programs, or that Good programs are Portable, or that Unix is
standard, is naive.  But deliberately pushing the boundaries of
what is conforming, or even worse, arguing that code which is
obviously dubious but which "obviously has to work" therefore
*must* work, is variously foolish, misguided, culpable, criminal,
and/or suicidal.


In article <4kbrt5$k3h@mulga.cs.mu.OZ.AU>, fjh@munta.cs.mu.OZ.AU
(Fergus Henderson) writes:
> seebs@solutions.solon.com (Peter Seebach) writes:
>> ... The [undefined] behavior you're used to...
>> is not a portability problem, it's broken code.)
> 
> It's a portability problem AND it's broken code.

What Fergus says is also true.  Where the distinction arises is
in one's reaction once the problem is discovered.  Some people
(I'd like to say most people) are aghast when they discover code
as broken as

	char buf[100]; read(fd, buf, 1000);

and hasten to fix it.  It seems that others, though, engage in
lengthy arguments about what some standard ought to say that the
code in question ought to do, as if the code in question ought to
do anything useful.

Let's not lose sight of the end goal here, which is neither to
spend the rest of our days arguing about standards nor fixing
bugs, but rather to write useful programs that work.  Yes, it's
hard to write a correct program.  Yes, it's even harder to write
an airtight standard.  Yes, compromises between the letter of a
standard and the peculiarities of existing practice are often
required when writing compilers.  But chortling with glee as you
discover that you can call read(fd, buf, 1000) even though buf is
only 100 characters long, because you've oh-so-cleverly noticed
and oh-so-carefully proved that fd can contain no more than 68
remaining characters, is not the sort of behavior that's likely
to lead to long-term stability of one's programs or adulation
from one's successors.  Nor, evidently, does coming back with
"But where does which standard say it's illegal?" immediately
endear you to some of your fellow supplicants on this mortal coil
here.

(Yes, the 68-character-buffer example is an extreme one, and no
one in this thread has been "chortling with glee."  But it's
reminiscent of the kind of arguments that come up all the time.)

The wise thing to do, it seems to me, is to fix the bugs and
overt portability problems, try to figure out better ways of
avoiding them in the future, and move on.  If the documentation
needs to be rewritten to make it clear that the N in "read() may
return -1, with errno set to EFAULT, if buf does not point to at
least N contiguous bytes of writable storage" is the N that is
read's third argument, then so be it.  (If the documentation
doesn't even mention EFAULT or buf's allocation, that may be a
bigger problem.)  Is there really anything else that needs
discussing here?

(Actually, of course, none of this needs discussing "here,"
where "here" is the set of newsgroups this thread is currently
crossposted to.  It probably belongs in comp.std.unix, or
comp.programming, or comp.software-eng.)

					Steve Summit
					scs@eskimo.com