Xref: utzoo comp.bugs.4bsd:1726 comp.lang.c:35786
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!pdn!tscs!tct!chip
From: chip@tct.uucp (Chip Salzenberg)
Newsgroups: comp.bugs.4bsd,comp.lang.c
Subject: Re: Complexity of reallocating storage (was users command crap)
Message-ID: <27AD7A46.343B@tct.uucp>
Date: 4 Feb 91 15:14:13 GMT
References: <5883:Feb102:05:4991@kramden.acf.nyu.edu> <1991Feb2.045119.22199@zoo.toronto.edu> <14994:Feb207:10:4791@kramden.acf.nyu.edu>
Organization: Teltronics/TCT, Sarasota, FL
Lines: 32

According to brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
>>    (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.

That particular "fatal" error -- disk failure -- will not kill the
program.  Instead, it will result in a pty program continuing to run
using wrong data that could have been detected and ignored.  This is
"good programming practice?"

>>    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.

Not to protect against that possibility is a strong temptation, but it
certainly is not "good programming practice."

>>      (void) chdir(newsuid);
>>     }
>
>Cannot fail.

Unless the mkdir() failed.
-- 
Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
 "I want to mention that my opinions whether real or not are MY opinions."
             -- the inevitable William "Billy" Steinmetz