🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.bugs.4bsd
Article #285

Re: Complexity of reallocating storage (was users command crap)

#285
From: Dan Bernstein
Date: Sat, 02 Feb 1991 07:10
58 lines
2426 bytes
In article <1991Feb2.045119.22199@zoo.toronto.edu> geoff@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
Technical Details
Message-ID: <14994:Feb207:10:4791@kramden.acf.nyu.edu>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!think.com!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd
References: <21548@yunexus.YorkU.CA> <5883:Feb102:05:4991@kramden.acf.nyu.edu> <1991Feb2.045119.22199@zoo.toronto.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!think.com!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.bugs.4bsd,comp.lang.c
Subject: Re: Complexity of reallocating storage (was users command crap)
Message-ID: <14994:Feb207:10:4791@kramden.acf.nyu.edu>
Date: 2 Feb 91 07:10:47 GMT
References: <21548@yunexus.YorkU.CA> <5883:Feb102:05:4991@kramden.acf.nyu.edu> <1991Feb2.045119.22199@zoo.toronto.edu>
Organization: IR
Lines: 58