Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!ficc!peter From: peter@ficc.uu.net (Peter da Silva) Newsgroups: comp.bugs.sys5 Subject: Re: AT&T system V fdopen mode checking Message-ID: <7190@ficc.uu.net> Date: 2 Dec 89 20:18:31 GMT References: <713@mbf.UUCP> <11723@smoke.BRL.MIL> Reply-To: peter@ficc.uu.net (Peter da Silva) Organization: Xenix Support, FICC Lines: 35 Doug Gwyn isn't often wrong, but... In article <11723@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: > In article <713@mbf.UUCP> hae@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: > -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. > O_RDONLY has nothing to do with the file. It is just a parameter to open(). Yes, a parameter that determines the mode of the file descriptor. When you try to write to a file opened O_RDONLY you will get an error EBADF. 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. -- `-_-' Peter da Silva. +1 713 274 5180. . 'U` Also or . "The basic notion underlying USENET is the flame." -- Chuq Von Rospach, chuq@Apple.COM