> -----Original Message-----
> From: Ronald F. Guilmette <r...@tristatelogic.com>
> Sent: Tuesday, January 14, 2020 8:16 AM
> To: austin-group-l@opengroup.org
> Subject: Re: A question on file flags after fork
> In message <mailto:1676199645.11146898.1578981958...@mail.yahoo.com>,
> Shware Systems <mailto:shwares...@aol.com> wrote:
> >Short answer, because both file descriptors reference the same file 
> >description...
> OK.  I see where I took a wrong turn now, however I must say that I cannot 
> blame myself for having done so.  The
> language being used for the base concepts here is exceptionally stilted.  We 
> have -descriptors- and then we have
> file -descriptions-.  I get it now, but I cannot help but wish that the 
> original drafters, way back when, had
> elected to be a bit less clever and bit more obvious in their coinage of the 
> relevant terminology here.  The
> term "file desctriptor" was grandfathered in from the ancient times of UNIX.  
> So that was cast in stone and
> could not be reasonably changed.  But I would have been a LOT happier if 
> those standard drafters, back in the
> day, had elected to call what is apparently now called a "file description" 
> something else... a "purple
> aardvark" or basically anything other that the thing they finally settled on, 
> which is extraordinarily subject
> to misinterpretation, being as it is, so close to the term "file descriptor".

I imagine people were reluctant to use "file table entry", as that implied a 
certain implementation (a table).

> Moving ahead, now that my misreading has been corrected, I'd like to just 
> throw out a trial balloon and note
> that it would be pragmatically useful to provide some attributes that are 
> currently associated only with "file
> descriptions" also for file descriptors.  O_NONBLOCK is the one that is most 
> immediately apparent to me, but I
> can readily imagine usefulness also for permitting things like O_APPEND and 
> even O_RDONLY and O_WRONLY to be
> applied selectively to individual file descriptors, rather than to (shared) 
> file descriptions.  I will happily
> elaborate on a real-world scenario in which this would have been most useful 
> to have, if anyone is interested,
> and also the ugly ccode contortions that had to be applied in order to 
> work-around this particular non- feature,
> which I am now aware is 100% standard conformant.

The point of O_RDONLY and O_WRONLY being fixed is that file access permission 
checking is done only during the
open(); the resulting file descriptor can be passed on to executables with a 
different (lesser) set of permissions.
Similarly, with O_APPEND, you want to make sure that, e.g., earlier log entries 
cannot be destroyed by later ones
by processes outside of your control.

I agree that the case for O_NONBLOCK is less clear and was surprised that this 
is not stored as part
of the file descriptor (although the name does give it away).

Reply via email to