> -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>,
>
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
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
|
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
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
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.
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
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
"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
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
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
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
12 matches
Mail list logo
