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