Complexity of reallocating storage (was users command crap)

[Dan Bernstein]

In article <1991Feb6.051432.2846 at zoo.toronto.edu> geoff at zoo.toronto.edu (Geoffrey Collyer) writes:
> I didn't exclude the XXX comment from the pty code excerpt to hide
> anything, it merely seemed redundant given the code that followed

But people drew several wrong conclusions exactly because you took the
code out of context.

> From pty.1:
> 	.SH BUGS
> 	None known, but they're probably hiding somewhere.
> Fascinating; this would seem to be at odds with the XXX comment.

What do you mean? You can have an infinite amount of defensive
programming, down to running a = b + c in triplicate and getting the
majority-vote result. Yes, defensive programming is A Good Thing, but
it's not required for a program to be correct.

> I also don't consider that code excerpt to be at all atypical of pty; I
> have read the entire pty source, and the excerpted code is fairly
> typical, in fact it was picked at random.

Geoff, maybe you believe what you're saying, but here are the facts.
There are 154 (void) casts in the pty source, and every ignored return
code is marked by a (void). 26 of those are in the section of code you
quoted and in two sister sections, and as I've explained (and as is
mentioned in the code) there should be more error checking there.

I really doubt that you would have chosen any other sections, and I
really find ``at random'' hard to believe.

C'mon, Geoff, you've made a sweeping generalization about my code, and
I say you're wrong until you provide some details. Here are the
justifications I used when writing the source:

21 of the ignored return codes are for sprintf(), strcpy(), and
strncpy(). Any complaints?

42 of those are for close(); 30 of the latter are upon descriptors that
haven't been used for I/O. In 4 of the remaining cases it might make
sense to report an error to the user upon failing close(); I am somewhat
convinced by now that it is worth checking close() in those cases to
deal with Sun's buggy network filesystem. Tally: 12 reasonable sources
of complaint, 4 where I'm inclined to agree.

8 are for setreuid() between the current real and effective userids. Now
there is absolutely no way they can fail, but as anyone who has the code
can verify, I was so concerned about the chance of security holes that I
made sure setreuid() worked before exec()ing a user program. Yes, Geoff,
that's such poor programming practice I could just cry.

Continuing on: 8 are for one-byte read(), one-byte write(), and fcntl(),
all to a pipe which spends its entire lifetime internal to one process;
I am tempted to say that those calls truly cannot fail, though I'm sure
that Sun will manage to mess this up too. Tally: 20/4.

14 are for kill() upon processes that must exist for the subsystem to be
internally consistent (such as the current pid). If, e.g., a renegade
sysadmin kills one of the processes, the worst that happens is that the
others block waiting for it. In 6 of those cases it's possible for an
error to occur and it would make sense to report the error. Tally: 20/10.

3 are for similar internal communication; any error in these cases will
actually be caught later. Tally: 23/10.

4 are for errors while printing an error message.

6 are for return codes that don't make sense as such: exit(), sleep(),
execvp() (which always returns -1), etc.

11 are for u area modifications (like signal() upon a known signal
number) that I really don't think will ever fail in any sane system. I
may be wrong, but unless someone can propose a sensible action to take
upon failure of signal(), I'm not going to check for it. Any complaints?

2 are for unlink()ing a bound UNIX-domain socket, in a section where
error reporting is difficult. The unlink()s can only fail if someone's
been futzing with the directory, and the worst that happens if they do
fail is that a few garbage inodes get used up and cleaned up later.
Tally: 25/10.

4 are for tty fchown()/fchmod() by root. In 2 of those cases an error
report makes sense, and these days I'm inclined to report such things.
Tally: 29/12.

4 are for restoring tty modes before printing an error message and
dying, and the final one is for changing window size---another case
where I'm not going to go crazy worrying about errors. (There's actually
a bug related to one of the tty restores---in one of the situations
where pty detects that the system is set up incorrectly---and I consider
that bug a hell of a lot more important than whether I catch close()
errors.) Tally: 29/12.


Okay, Geoff. There are a few related, isolated sections of code where I
really didn't catch errors; you just happened to pick one of those three
sections to quote out of context. Now you say that those sections---with
some 26 ignored return codes altogether---are typical of the entire
program. Are you willing to go back through the code and think that
through again? I simply don't believe that you can possibly give
reasonable complaints about more than 29 of the other return codes, none
disastrous and all perfectly justifiable.

And remember that we're talking about a program with around 2000 calls
altogether. Compared to ``professional'' Berkeley source, any code that
checks practically every return code is what some people would call
paranoid.

> Given your cavalier disregard for errors and apparent incomprehension
> of possible sources of error,

Before this you were giving reasonable criticism, but now I'm insulted.
Cavalier disregard for errors? Wtf are you talking about? Apparent
incomprehension of possible sources of error? What higher plane did you
come from? In my response to your article I began by noting the
possibility of hard I/O errors; the same thing is in the comment above
the code that you ripped out of context. I even mentioned the obscure
possibility that a sysadmin is actively trying to destroy the internal
communication of the program. Duh, you're so right, Geoff, it's
perfectly apparent from my articles that I have complete faith in
nothing ever going wrong. Hell, that's why I'm a syslog fanatic:
security holes and reliability problems don't exist.

> I don't think you are in any position to
> criticise another's programming technique, let alone Ozan's.

When someone says that a small number of passes is an important goal in
and of itself, he's being silly. Unless reducing passes actually has a
good effect (like reducing time, space, or human effort), nobody cares.
As others have pointed out, you can make programs run just awfully by
aiming for single-pass solutions. I think even the worst programmer
would be justified in criticizing Ozan's statement about the number of
passes as long as he doesn't make the mistake himself.

> I shall
> be polite here and refrain from any further comment on the programming
> technique so stunningly displayed by pty.

No, you've already stopped being polite. I once again invite anyone who
wants to see the actual programming technique of pty---rather than its
inaccurate renderings by Geoff---to look at the code for himself.

> And I'm not going to argue this for ten weeks.

But you're making statements that, for example, imply that pty ignores
most return codes. That's simply wrong, and I hope you have the
integrity to correct what you said.

If I didn't have as much respect for you and your work, this article
would be a lot shorter (and a hell of a lot less polite). Something like
``[Expletive] you, [expletive], you don't know what the [expletive]
you're talking about. Except for sprintf(), close(), signal(), and
strncpy(), pty checks for errors on 96% of its calls. Did you write any
packages last May with 5500 lines of documentation and 4500 lines of
code? How many errors did you check? How many years have you been a
systems programmer?''

Surely you admit that this would be a natural response to someone who
says ``These twenty lines of code [which don't check return codes] are
typical of the entire package.'' Can you see how that would anger me?
It's neither constructive nor accurate. It doesn't help me improve my
code, and its main effect would be to damage my reputation.

When I saw your first article, I assumed that you were just a tad
annoyed by my comments about Ozan's new programming principle. I saw
that you had selected one of the few remaining spots in the code which
did very little error checking. Fair enough: I deserved the reminder.
I didn't realize that the context you took away---the comment, and the
variables, and the fact that the process doesn't have stderr---would
give people such misimpressions about the code. But it did, and you were
wrong to remove the context.

Now you say that the section of code you quoted is ``fairly typical'' of
the entire program. How so? In the sparsity of comments? There are
comments throughout the code, and there's a big file with design notes
on the structure of pty. No, you're saying that my program doesn't check
its errors, and you're wrong about that.

Sure, I'm glad that you had the time and interest to read the pty code.
I'm sorry that I flamed Ozan---in the amoral, objectivist sense that I
see more loss than gain in what I did, and I've made a mental note to do
it more politely next time. I'm glad that you pointed out a section of
code you don't like in pty. But all of these pale beside the spectacle
of someone I respect giving an almost entirely inaccurate assessment of
my biggest (and, I'd say, best) program last year. I can't stand by
emotionlessly and watch you do this. I hope you'll at least send me a
note saying that pty isn't the programming disaster you've made it out
to be.

> Don't you have a job or
> thesis to keep you busy?

The former---but at this time in the morning? Be serious. :-)

Followups to the nonexistent group comp.programming---although this
thread is somewhat related to both programming in C and programming in
UNIX, it's really about more general issues. I don't expect followups
from anyone except Geoff, and I assume he'll pick the right groups.

---Dan