Date: Mon, 13 Jan 2020 23:16:03 -0800
From: "Ronald F. Guilmette" <r...@tristatelogic.com>
Message-ID: <39544.1578986...@segfault.tristatelogic.com>
| OK. I see where I took a wrong turn now,
In which case the lengthy reply I just sent can be ignored...
| 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.
That is true, and is the nature of standards, and also legal documents.
They must be read particularly carefully, even the slightest variation
can mean something entirely different. This is all in the nature of
aything where absolute precision is required.
| 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".
Perhaps, but that won't be the only thing like this that you find.
| 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.
Not in both places, that would be a minefield.
| O_NONBLOCK is the one that is most immediately apparent to me,
As I said in the previouys (long) reply, I think O_NONBLOCK was put
in the wrong place initially (though I suspect there were reasons).
| but I can readily imagine
| usefulness also for permitting things like O_APPEND
append mode is a less clear case, typically it wants to be shared.
| and even O_RDONLY and O_WRONLY to be applied selectively to
| individual file descriptors,
No, those cannot be, the permission checks are made only at open()
time, and after that the system assumes that if you have a file open
for read, then you have permission to read it (etc) - that's how a
setuid process can open a file, and then setuid(getuid()) to drop
its setuid status, and still continue to read the file, even though
it would not have permission to open the file for reading if it
attempted to open the file again now.
Those can only be set at open time, and consequently must apply to
everything that references the same file table entry ("file description").
Almost everything that can be traced back to the original unix design
has a very good reason for being exactly like it is. Unfortunately,
non-blocking I/O is a more recent addition, and not all of those were
nearly as carefully thought out.
kre
