System call error handling

[Chip Salzenberg]

[ Followups to comp.unix.programmer, since UNIX system call
  error handling is the current subject. ]

According to brnstnd at kramden.acf.nyu.edu (Dan Bernstein):
>Summary: Chip complains that a read() from disk into a ``newuid''
>integer may fail and hence have pty switch to the wrong uid. But I
>explicitly initialized newuid to uid just to handle this possibility.

That's fine for pty, unless the file is less than sizeof(int) bytes
long, in which case the initialization will not help.  Also, a disk
read error is worth reporting, no matter when it occurs, or to whom.

I would suggest, then, that pty should have code like this:

    if ((rd = read(fd, (char *)&newuid, sizeof(int))) != sizeof(int))
    {
        if (rd == -1)
            fprintf(stderr, "pty: can't read uid file %s: %s\n",
                    filename, strerror(errno));
        else
            fprintf(stderr, "pty: corrupt uid file %s\n", filename);
        newuid = uid;
    }

Yes, it's tedious.  But to omit tests for these possibilities when
there is something to be done is poor programming practice, with no
ifs, ands or buts.  (Printing an error message _is_ doing something.)

>Die with a fatal error, possibly killing a truly critical system program
>running under pty?

Death is irrelevant to the issue; it is also, in this case,
unnecessary.  Reporting unexpected system call errors is neither.

>Nobody's programming is perfect; the best I hope I can say is that I've
>gotten better over the years.

I would have to say the same thing about my own programming; so would
anyone with a modicum of honesty.  But the fact that one's programming
is better today than yesterday should -- I repeat, _should_ -- cause
one to be at least _polite_ when criticizing another's code.  The ego
you save may be your own.

>Don't you read code before you criticize it?

Context is always important.  But there are some things that you just
_don't_ mess around with, and user ids are at the top of the list.

>Chip, be reasonable. You can't demand of system programs that they check
>for external system consistency at every step.

Oh, really?  Read Deliver 2.0 PL12 and make that statement again.
-- 
Chip Salzenberg at Teltronics/TCT     <chip at tct.uucp>, <uunet!pdn!tct!chip>
 "Most of my code is written by myself.  That is why so little gets done."
                 -- Herman "HLLs will never fly" Rubin