Complexity of reallocating storage (was users command crap)

[Dan Bernstein]

In article <1991Feb2.045119.22199 at zoo.toronto.edu> geoff at zoo.toronto.edu (Geoffrey Collyer) writes:
> Dan Bernstein, in response to Ozan Yigit:
> > To rephrase: You don't seem to know what good programming techniques are.
> From pty/master.c:

Yes, what's your point? I have several hundred notes on pieces of pty
that could be improved. In the list I find ``check for phys I/O errors
on reading fdsess''; that's the only problem with the section of code
you quoted.

Are you worried about all the ignored return codes? I'll go through them
one by one. Sure, I could've programmed more defensively, but the only
possible response to a fatal error would be cutting off the user program
from its input and output.

>    (void) lseek(fdsess,(long) 0,0);

This is guaranteed to work. The third 0 could be changed to some
symbolic constant (like L_SET), but as you know 0 is more portable.

>    (void) read(fdsess,(char *) &newuid,sizeof(int));

This is guaranteed to work, because fdsess is a regular file that was
created with at least the int. The only possible problem is a hard I/O
error or other fatal system error.

>    (void) sprintf(newsuid,"%d",newuid);

This is guaranteed to work; newsuid has enough space.

>    (void) chdir("..");

This is guaranteed to work.

>    if (chdir(newsuid) == -1)
>     {
>      (void) mkdir(newsuid,0700);

This cannot fail unless some renegade sysadmin changes the mode of the
session directory while pty is running. 0700 could be made a symbolic
constant too, but see above.

>      (void) chdir(newsuid);
>     }

Cannot fail.

>    (void) sprintf(foo,"../%d/%s",uid,fnsess);
>    (void) rename(foo,fnsess);

Guaranteed to work, as above.

>    (void) sprintf(foo,"../%d/%s",uid,fnre);
>    (void) rename(foo,fnre); /* in case we're already disconnected */

Ditto.

---Dan