Article View: comp.bugs.4bsd
Article #285Re: Complexity of reallocating storage (was users command crap)
From: Dan Bernstein
Date: Sat, 02 Feb 1991 07:10
Date: Sat, 02 Feb 1991 07:10
58 lines
2426 bytes
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!brnstndReferences:
<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