Path: utzoo!attcan!uunet!cs.utexas.edu!sun-barr!newstop!texsun!letni!lawnet!mbf!hae
From: hae@mbf.UUCP (Hae Hirdler)
Newsgroups: comp.bugs.sys5
Subject: Re: AT&T system V fdopen mode checking
Message-ID: <771@mbf.UUCP>
Date: 7 Dec 89 01:58:47 GMT
References: <713@mbf.UUCP> <7190@ficc.uu.net> <1989Dec3.130758.27151@virtech.uucp>
Organization: MAI Basic Four, Inc.,  Tustin, CA
Lines: 26

In article <1989Dec3.130758.27151@virtech.uucp>, cpcahil@virtech.uucp (Conor 
P. Cahill) writes:
>>In article <7190@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes:
>>...   
>>The manual is correct, you should make the modes agree. The code doesn't
>>check, so you won't get an error, but don't do it anyway.
>
>The code can, and should, check.  These capabilities have existed since 
>System V.2 and at least 4.3BSD (not sure about prior BSD releases.

I agree with both of the responses.

We could say that 'the manual is correct' in the sense that it plants a bomb
if the mode of fdopen() doesn't match with the oflag of the open()'ed file, 
and it will explore when fclose() or fflush() is called.  

But, I think that the man page is misleading in the sense that, if no 
error is received after fdopen(), it may let you assume that everything 
is ok so far.   This will only make a debugging harder.  I don't see what 
we are gaining here with this sneaky attack.  

To fully support the man page statement, I think the fdopen() code should 
be modified to include the error checking on the mode.  (Specially, now the 
tools are available - fcntl(fd, F_GETFL), as Conor P. Cahill points out.)  

	- hae hirdler