From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 109fba,df854b5838c3e14
X-Google-Attributes: gid109fba,public
X-Google-Thread: 1014db,df854b5838c3e14
X-Google-Attributes: gid1014db,public
X-Google-Thread: 103376,df854b5838c3e14
X-Google-Attributes: gid103376,public
From: dewar@cs.nyu.edu (Robert Dewar)
Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
Date: 1996/04/10
Message-ID: <dewar.829185159@schonberg>#1/1
X-Deja-AN: 146856784
references: <dewar.828936837@schonberg> <828964950snz@genesis.demon.co.uk>
 <dewar.828987544@schonberg> <4kb2j8$an0@solutions.solon.com>
 <4kbrt5$k3h@mulga.cs.mu.OZ.AU> <DpnxAF.6xq@eskimo.com>
organization: Courant Institute of Mathematical Sciences
newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++
Date: 1996-04-10T00:00:00+00:00
List-Id: <comp.lang.ada>

Steve said/asked

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

Of course it is being brought up as an example of a portability problem.
As for

  (a) should be written
  (b) should be portable in practice
  (c) should work

I would say, historically, (b) and (c), but not necessarily (a). If the
spec of the POSIX read were defined to say "the buffer must be at least
as long as the data that is read", then certainly (b) and (c) would be
true. As for (a), note that of course *no one* would explicitly write
the dubious code, it occurs in the context of a loop, something like

   while (p < endbuf) {read(fd, p, 8192); p+=8192;)

where the precondition is that the data read from fd is known not to
go "past" endbuf. Of course it is possible to modify this code so that
the last read does not have an excessive count, but the resulting code
is a little more complex.

The issue is not whether this code is defensible or not. Clearly this was
in fact a significant bug, since the code broke on Linux, and this was
intended to be portable, so it was wrong, caused trouble, and had to be
fixed. In that sense it was certainly wrong!

However, given the vague definition of read, it is easy to see how the
coder here in fact assumed that (b) and (c) were true, and hence the
bug arose.

If the spec of read had said: "the buffer must be at least the length
given by the third parameter, even if the actual data is smaller", then
of course the error would not have been made in the first place. And that,
all along has been my point. Careful specification of interfaces, and
accurate knowledge of these specifications, can definitely improve
portability.