AT&T system V fdopen mode checking

[Conor P. Cahill]

In article <7190 at ficc.uu.net>, peter at ficc.uu.net (Peter da Silva) writes:
> Doug Gwyn isn't often wrong, but...
> 
> In article <11723 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn) writes:
> > In article <713 at mbf.UUCP> hae at mbf.UUCP (Hae Hirdler) writes:
> > -The man page on the fdopen states that "the type of the stream must 
> > -agree with the mode of the open file."
> 
> > I believe by "mode" they mean "file access permissions".
> 
> No, they mean the second argument to open(). But I don't believe it's
> possible to determine what the mode of a file descriptor is by examining
> it, so:

Yes it is.  fcntl(fd,F_GETFL) returns the status flags of an open file 
descriptor.

> > -For example, fd= open(filename, O_RDONLY); fptr= fdopen(filename, "w")
> > -will return a NON_NULL fptr value instead of NULL.  
> 
> Yes, but writes to the file may fail. There's no safe way of checking this
> from fdopen. I suppose a write(fd, "", 0) will work as a check. I don't
> know what this might do on some files (tape drives, for example).
> 
> I said may, not will, because if the file descriptor refers to a terminal
> you can write to it even if it's opened O_RDONLY.

This is not true on System V and I would expect it to not be true on any
unix system because the access mode for a file descriptor is checked before
any call to a device driver read/write routines.  

What you may be confusing it with is the ability to do a

		fdopen(0,"w");

to get another file pointer to stdin, but this file descriptor is really
opened for read and write, so the fdopen() for a subset of the capabilities
will succeed (and work).

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


-- 
+-----------------------------------------------------------------------+
| Conor P. Cahill     uunet!virtech!cpcahil      	703-430-9247	!
| Virtual Technologies Inc.,    P. O. Box 876,   Sterling, VA 22170     |
+-----------------------------------------------------------------------+