RE: A question on file flags after fork

[Schwarz, Konrad]

> -Original Message-
> From: Ronald F. Guilmette 
> 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).

Re: A question on file flags after fork

[Ronald F. Guilmette]

In message <16937.1578995...@jinx.noi.kre.to>, 
Robert Elz  wrote:

>But you do need some experience reading standards...

I would like to pause just longe enough to thank you all for the
unambiguously patronizing and derogatory manner in which you have
welcomed me into your community, all due apparently to my unforgivable
inability to instantly grasp the fine and semantically critical
distinction between the words "descriptor" and "description".

For the record, I served in the 1990s on both the C9X standardization
committee and also the original C++ standardization committee,  the
former with what I believe could be called distinction, since in that
instance I contributed a quite sizable number of both questions and
clarifications which were deemed of value to that effort.  Separately,
I was a major contributor to the standardization of DWARF syntax and
semantics which, if you have ever found yourselves debugging any
program in any compiled language on any modern *NIX system you have
most probably benefitted from.

I will be leaving you now, in peace.  My sincere apologies for having
disturbed your deliberations.  You have certainly succeeded in persuading
me that I am unworthy of even asking a question, at least not here,
but I shall most certainly be recommending this group and this mailing
list to any of my cohorts who feel themselves to be inadequately
demeaned by their spouses and/or immediate family members.


Regards,
rfg

Re: A question on file flags after fork

[Robert Elz]

Date:Mon, 13 Jan 2020 23:16:03 -0800
From:"Ronald F. Guilmette" 
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

Re: A question on file flags after fork

[Robert Elz]

Date:Mon, 13 Jan 2020 20:26:33 -0800
From:"Ronald F. Guilmette" 
Message-ID:  <38942.1578975...@segfault.tristatelogic.com>

  | While developing some C code recently, and testing that, I came upon a
  | VERY surprising and unexpected result.  It appears that various flavors
  | of *NIX are in agreement that after a fork, the set of flag bits (e.g.
  | O_NONBLOCK) that are associated with any specific file descriptor that
  | was open prior to the fork will, after the fork, exist only as a single
  | shared set of flag bits... *not* one copy for the parent and a separate
  | set for the child.

That is correct.

  | My reading of both the old and faded hardcopy of the 1993 POSIX API
  | standard that I have here, as well as the newer draft

If you can point at language in the current draft that suggested the
interpretation you have, and I agree it can be read the way you are
reading it, then I will file a defect report, as that would be incorrect.

Remember that the standard describes the way the implementations work
(which as you pointed out is the same for this issue, everywhere), it
does not legislate how they must behave (though to claim to conform one
must imlement what the standard reqires ... very few of the free OS versions.
if any, claim to conform howwver).But the standard should be able to
be used by people like you so you can correctly understand the way that
systems work (including the places where different implementations are
different - not that that is relevant here).  So if you are reasonably
interpreting the standard to say something it shouldn't, it should be
corrected.

But you do need some experience reading standards, they are not intended
as tutorials - and the language tends to be very precise, a slight difference
in wording, which in normal text would signify nothing at all, in a
standard can entirely change the meaning of what was said (which is similar
in a way to legal documents, like statutes, contracts, etc - the language is
very precisely defined.)

  | I have prepared two short example programs exclusively to illustrate the
  | issue.

There was no real need, we all know (and expect) the behaviour you mentioned.

But no, sorry, I do not have time to trawl through the standard looking
for where it says how things should work, but I will look at any text you
point out to me which you believe says something different.

(Give references to the 2018 draft, not the ancient 1993 version, much
has changed in that period.   You can reference section numbers, page
numbers, or line numbers (but also quote the text in question))

  | This occurs in both cases shortly after the recently forked child processes
  | have expressely and deliberately un-set the O_NONBLOCK flag for a file
  | descriptor that they have inherited a copy of at the time of the preceeding
  | fork.

That is what is supposed to happen.

  | How can diddling the flags for one file descriptor cause the flags of a
  | different file descriptor to magically change also?

Short (or not so short) answer, references to files in unix pass through
three levels of indirection.   This is ancient, from the earliest days.

At the bottom (close to the file) there is the inode (or vnode, or ...)
which is the actual description of a file, and contains all of the file's
data (the content of the file, and the meta-data like owner, access/modify
times (etc), permission bits, ...)   That one is identified by the combination
of an "inode number" and device (description of the filesyste, in which the
inode is housed).(File names are simply data in directories that map
human strings to inode numbers - the device for the inode is the same as
the device holding the directory  Names have files, files do not have
names).

Next up is the file table.   An entry in this is created for each open()
(and similar operations, like socket() etc) - the operations that create
a file descriptor from other data (a file name in the case of open()).
This is a single global shared table accessed by all of the processes
currently running.   There can be many file table entries referencing the
same file, for example
fd1 = open("file", ...);
fd2 = open("file", ...);
fd3 = open("file", ...);
will generate 3 different file table entries.   Each entry contains a
reference to the inode (all 3 of these would reference the same one),
plus the access mode (read/write/read-write) (one of the missing parameters
buried in the elipsis above) the current file offset, and almost all of
the mode flags relating to the file (all the ones that can be manipulated
using the fcntl(F_SETFL, ...) and fcntl(F_GETFL, ...) operations.  That
includes the non blocking mode.

Next up is the process file descriptor table.   This maps the small
integer file descrioptors (0, 1, 2, ...) that each process is given
from open() (etc) to references to the file table.   All the system
calls that manipulate file descriptors are 

Re: A question on file flags after fork

[Don Cragun]

Hi Danny and Ronald,
The austin-group-l e-mail list is a perfectly fine place to discuss the 
contents and interpretation of the current standard as well as the development 
of future revisions and amendments to the standard.  Places like 
unix.stackexchange.com and unix.com are fine places to go when you have 
questions about how to do something on BSD, Linux, and UNIX systems especially 
when discussing features that have not been standardized (jand frequently vary 
considerably in various versions of those operating systems, and, to a lesser 
degree even in various releases of a given version operating systems).

Any time you want an official interpretation of the standard, this is the place 
to come.

Hi Ronald,
The terms "file descriptor" and "file description" are both taken directly fro 
historic UNIX system documentation; neither was invented by developers of the 
standard.  Historic UNIX system man pages from 40 years ago seldom spelled out 
the relationship between those two terms as well of the current standard does.  
For example, the first two paragraphs of the DESCRIPTION section of the open() 
function man page (from page 1408, lines 46754-46762 in the 2017 edition of the 
standard):

The open() function shall establish the connection between
a file and a file descriptor. It shall create an open file
description that refers to a file and a file descriptor that
refers to that open file description. The file descriptor is
used by other I/O functions to refer to that file. The path
argument points to a pathname naming the file.

The open() function shall return a file descriptor for the
named file, allocated as described in Section 2.14 (on page
549). The open file description is new, and therefore the
file descriptor shall not share it with any other process in
the system. The FD_CLOEXEC file descriptor flag associated
with the new file descriptor shall be cleared unless the
O_CLOEXEC flag is set in oflag.

tries to clearly specify the relationship between the file descriptor and the 
file description that are created by a successful call to open().  Note also 
that the magic phrase "as described in" is almost always followed by a 
hyperlink in the PDF and in the HTML versions of the standard that you can 
click on to see that description.

We all realize that there are a lot of defined terms that you need to 
understand while reading the standard and that until you are used to the level 
of detail specified, it is easy to get confused.  When you use the standard 
frequently you get used to the terms used and learn where to find the 
definitions of those terms.  (Look especially at chapter 2 of the System 
Interfaces and Headers volume of the standard and at chapter 3 of the Base 
Definitions volume of the standard.  If you understand the concepts and 
definitions in those two places, many of your questions will have been 
answered.)

I hope this helps and look forward to seeing more of your questions in the 
future.

Sincerely,
Don Cragun
IEEE Portable Applications Standards Committee organizational representative to 
The Austin Group

> On Jan 13, 2020, at 11:25 PM, Ronald F. Guilmette  
> wrote:
> 
> In message , 
> Danny Niu wrote:
> 
>> Anyway, this mailing list should focus on **standard development**, 
>> questions like this of yours should go to places like unix.stackexchange.com.
> 
> I can only thank you for your kindness, grace, generosity, and understanding.
> I'm sure that these will all inspire others more worthy than myself to wish
> to contribute meaningfully to the ongoing standardization effort.
> 
> Regards,
> rfg
> 

Re: A question on file flags after fork

[Shware Systems]

I don't blame you either; I've always preferred file handle to file descriptor, 
for that reason. As it is, the full list of flags is part of open(); fcntl only 
has FD_NONBLOCK because this is the only flag considered safe to modify while a 
file is open, however many times it's referenced. Changing from O_RDONLY to 
O_APPEND on the fly can be problematic to applications using pread(), for 
example, to access records from a database in parallel.
On Tuesday, January 14, 2020 Ronald F. Guilmette  wrote:
In message <1676199645.11146898.1578981958...@mail.yahoo.com>, 
Shware Systems  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".

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.


Regards,
rfg

Re: A question on file flags after fork

[Ronald F. Guilmette]

In message , 
Danny Niu wrote:

>Anyway, this mailing list should focus on **standard development**, 
>questions like this of yours should go to places like unix.stackexchange.com.

I can only thank you for your kindness, grace, generosity, and understanding.
I'm sure that these will all inspire others more worthy than myself to wish
to contribute meaningfully to the ongoing standardization effort.

Regards,
rfg

Re: A question on file flags after fork

[Ronald F. Guilmette]

In message <1676199645.11146898.1578981958...@mail.yahoo.com>, 
Shware Systems  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".

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.


Regards,
rfg

Re: A question on file flags after fork

[Danny Niu]

"File Descriptor" and "Open File Description" are in section 3 "Definitions" of
the "Base Definitions" volume, 

As to the one "Close-On-Exec" flag, you can Ctrl-F "FD_CLOEXEC" in the 
header and you'll see it's the only one listed. 

Anyway, this mailing list should focus on **standard development**, 
questions like this of yours should go to places like unix.stackexchange.com. 

在 2020-01-14 14:07:23，“Ronald F. Guilmette” 写入:

In message , 
Danny Niu  wrote:

>To a process, a "file descriptor" is a pointer to the "open file 
description" in 
>the kernel-administered memory space/range. The two are related, but have
>different set of flags. 

Can you point to specific passages of the stadard, or draft standard, that
support either of those assertions?

>The currently (only) defined flag for "file descriptor" is the 
"close-on-exec"
>flag where as there's many more flags for the "open file description". 

Same question.  Can you quote chapter and verse from the actual standard, or
draft standard, to supoprt what you have asserted?

>You can find out more about the 2 concepts in the base volume. Hope this 
helps. 

Not really.  But I appreciate the effort.


Regards,
rfg

RE: A question on file flags after fork

[Shware Systems]

Short answer, because both file descriptors reference the same file 
description, ala a dup() being called, the SETFD modifying that description is 
visible in both processes through that file descriptor. A reopen() that 
attaches the reference in the child to a new description is needed for the 
operation to be independant of the parent. The copy mentioned is of the fd 
values being "in use", that's all.

On Monday, January 13, 2020 Ronald F. Guilmette  wrote:


Greetings all.  This is my first post here and I hope you will all be

kind in light of that.



I need to pose a question of interpretation.



While developing some C code recently, and testing that, I came upon a

VERY surprising and unexpected result.  It appears that various flavors

of *NIX are in agreement that after a fork, the set of flag bits (e.g.

O_NONBLOCK) that are associated with any specific file descriptor that

was open prior to the fork will, after the fork, exist only as a single

shared set of flag bits... *not* one copy for the parent and a separate

set for the child.



My reading of both the old and faded hardcopy of the 1993 POSIX API

standard that I have here, as well as the newer draft that Mr. Andrew

Josey was kind enough to point me at today strongly suggest to me that

the implementations I have tested (Linux + FreeBSD) are not conforming

to what is actually on the printed page, either in the 1993 IEEE standard

or in the newer 2018 draft that I am looking at now.



I have come here to solicit opinions on this point.



I have prepared two short example programs exclusively to illustrate the

issue.  The first illustrates the issue with respect to ordinary file

descriptors, while the second does so with respect to message queues.

(But the results, when tested against real current implementations, are

identical for both example programs and thus perfectly consistant with

one another, shoing that wether this behavior if confirmant to the standard

or not for both types of descriptors, at least there is consistancy. :-)



These two short example programs may be found at the following links:



    https://pastebin.com/raw/AKuWJvyS

    https://pastebin.com/raw/KdhKt2Ya



In both cases, the programs end up printing:



    O_NONBLOCK magically unset in parent



This occurs in both cases shortly after the recently forked child processes

have expressely and deliberately un-set the O_NONBLOCK flag for a file

descriptor that they have inherited a copy of at the time of the preceeding

fork.



To me, this outcome was beyond surprising, and in conversations with a dear

friend I likened it to the infamous "spooky action at a distance" of quantum

mechanics, which none other than Albert Einstein famously found so troubling.



I am no Einstein by any streatch of the imagination, but like him I also

find this "spooky action at a distance" most disconcerting and also

inexplicable.



How can diddling the flags for one file descriptor cause the flags of a

different file descriptor to magically change also?  At the present moment

this still makes no good sense to me, and as I have said, it appears to me

to be inconsistant with the plain language of the standard as written.

I can and will expound upon this point, as may be necessary, but for now

I would prefer to just get some feedback from you folks.



I am fairly thick skinned, so by all means, please feel free to tell me

if you think I'm just crazy, and if in fact the standard does not mean

what it says when it says "The child process shall have its own copy of

the parent's file descriptors."



Thank you all for your attention.





Regards,

rfg

Re: A question on file flags after fork

[Ronald F. Guilmette]

In message , 
Danny Niu  wrote:

>To a process, a "file descriptor" is a pointer to the "open file description" 
>in 
>the kernel-administered memory space/range. The two are related, but have
>different set of flags. 

Can you point to specific passages of the stadard, or draft standard, that
support either of those assertions?

>The currently (only) defined flag for "file descriptor" is the "close-on-exec"
>flag where as there's many more flags for the "open file description". 

Same question.  Can you quote chapter and verse from the actual standard, or
draft standard, to supoprt what you have asserted?

>You can find out more about the 2 concepts in the base volume. Hope this 
>helps. 

Not really.  But I appreciate the effort.


Regards,
rfg

Re: A question on file flags after fork

[Danny Niu]

Hi there Ron. 

I'm not a standard developer, I'm just an outsider who happens to have 
Interest in the Unix standardization activities. 

To a process, a "file descriptor" is a pointer to the "open file description" 
in 
the kernel-administered memory space/range. The two are related, but have
different set of flags. 

The currently (only) defined flag for "file descriptor" is the "close-on-exec" 
flag, 
where as there's many more flags for the "open file description". 

You can find out more about the 2 concepts in the base volume. Hope this helps. 

在 2020-01-14 12:27:30，“Ronald F. Guilmette” 写入:

Greetings all.  This is my first post here and I hope you will all be
kind in light of that.

I need to pose a question of interpretation.

While developing some C code recently, and testing that, I came upon a
VERY surprising and unexpected result.  It appears that various flavors
of *NIX are in agreement that after a fork, the set of flag bits (e.g.
O_NONBLOCK) that are associated with any specific file descriptor that
was open prior to the fork will, after the fork, exist only as a single
shared set of flag bits... *not* one copy for the parent and a separate
set for the child.

My reading of both the old and faded hardcopy of the 1993 POSIX API
standard that I have here, as well as the newer draft that Mr. Andrew
Josey was kind enough to point me at today strongly suggest to me that
the implementations I have tested (Linux + FreeBSD) are not conforming
to what is actually on the printed page, either in the 1993 IEEE standard
or in the newer 2018 draft that I am looking at now.

I have come here to solicit opinions on this point.

I have prepared two short example programs exclusively to illustrate the
issue.  The first illustrates the issue with respect to ordinary file
descriptors, while the second does so with respect to message queues.
(But the results, when tested against real current implementations, are
identical for both example programs and thus perfectly consistant with
one another, shoing that wether this behavior if confirmant to the standard
or not for both types of descriptors, at least there is consistancy. :-)

These two short example programs may be found at the following links:


https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2Fraw%2FAKuWJvySdata=02%7C01%7C%7C646865780eaf4d849a7308d798aa1073%7C84df9e7fe9f640afb435%7C1%7C0%7C637145728496131504sdata=fBbIB618OP%2F5l%2F9HOf80YIErBI8yW4eWNlL%2BWx%2F57wI%3Dreserved=0

https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2Fraw%2FKdhKt2Yadata=02%7C01%7C%7C646865780eaf4d849a7308d798aa1073%7C84df9e7fe9f640afb435%7C1%7C0%7C637145728496131504sdata=Z1jaIkYhoSt8m28S4i4vCCzgEjBOZScCAOBTfjaPJiU%3Dreserved=0

In both cases, the programs end up printing:

O_NONBLOCK magically unset in parent

This occurs in both cases shortly after the recently forked child processes
have expressely and deliberately un-set the O_NONBLOCK flag for a file
descriptor that they have inherited a copy of at the time of the preceeding
fork.

To me, this outcome was beyond surprising, and in conversations with a dear
friend I likened it to the infamous "spooky action at a distance" of quantum
mechanics, which none other than Albert Einstein famously found so 
troubling.

I am no Einstein by any streatch of the imagination, but like him I also
find this "spooky action at a distance" most disconcerting and also
inexplicable.

How can diddling the flags for one file descriptor cause the flags of a
different file descriptor to magically change also?  At the present moment
this still makes no good sense to me, and as I have said, it appears to me
to be inconsistant with the plain language of the standard as written.
I can and will expound upon this point, as may be necessary, but for now
I would prefer to just get some feedback from you folks.

I am fairly thick skinned, so by all means, please feel free to tell me
if you think I'm just crazy, and if in fact the standard does not mean
what it says when it says "The child process shall have its own copy of
the parent's file descriptors."

Thank you all for your attention.


Regards,
rfg