Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.bugs.sys5
Subject: Re: AT&T system V fdopen mode checking
Message-ID: <2690@auspex.auspex.com>
Date: 6 Dec 89 18:32:22 GMT
References: <713@mbf.UUCP>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 36

>The man page on the fdopen states that "the type of the stream must 
>agree with the mode of the open file."  But, when a file is open()'ed
>( fd= open (filename, oflag) ), and fdopen()'ed for a stream 
>( fptr= fdopen (fd, mode) ), it allows this open file to be opened for 
>any type of a stream regardless of the type of oflag already open()'ed. 
>For example, fd= open(filename, O_RDONLY); fptr= fdopen(filename, "w")
>will return a NON_NULL fptr value instead of NULL.

A non-null but useless "fptr" value.  "Must" can either be read as
"'fdopen()' will reject your request if the type of the stream does not
agree with the mode of the open file" or "if the type of the stream does
not agree with the mode of the open file, the resulting stream won't be
usable."  It doesn't explicitly say that it does those checks, so an
implementation that doesn't perform them is valid.

Prior to the appearance of the "fcntl()" call in System III it would, in
fact, have been impossible to perform those checks without potential
risk to the file; the only way to find out if a file descriptor is open
for reading was to try and read it, and the only way to find out if a
file descriptor is open for writing was to try and write to it....

I suspect they either didn't even consider the possibility of adding
those checks once "fcntl" allowed you to see the file descriptor flags,
or they considered it unnecessary to do so, since presumably a
programmer is smart enough not to ask the system to make a standard I/O
stream open for writing out of a file descriptor open for reading.... 
(If the "fdopen()" is buried inside a routine that can be handed an
arbitrary file descriptor and/or an arbitrary open mode, the argument is
merely applied to calls to that routine rather than calls to
"fdopen()".)

>The semantics of the man page on the fdopen seems to indicate that 
>this should not be allowed. (return NULL)  

Nope.  It doesn't say so explicitly; it doesn't, in fact, indicate what
the possible failure modes of "f*open()" are.