From: Joseph Myers <joseph@codesourcery.com>
To: "Arsen Arsenović" <arsen@aarsen.me>
Cc: <libc-alpha@sourceware.org>
Subject: Re: [PATCH v2] Ensure standard file descriptors are open on start
Date: Wed, 19 Aug 2020 16:28:25 +0000 [thread overview]
Message-ID: <alpine.DEB.2.21.2008191622010.32578@digraph.polyomino.org.uk> (raw)
In-Reply-To: <20200819124124.17481-1-arsen@aarsen.me>
On Wed, 19 Aug 2020, Arsen Arsenović via Libc-alpha wrote:
> ISO C requires that standard input, output and error are always open on
> program startup.
ISO C doesn't talk about file descriptors at all. The objects stdin,
stdout and stderr need to be initialized, but it's fine for all I/O on
them to fail.
> + /* Ensure the standard streams are opened, as required by POSIX and C. For
> + dynamic programs this is already handled in the dynamic loader. */
Please give specific references, not just "as required by POSIX and C".
What exactly do you think requires these descriptors to be open? The
POSIX specification for execve explicitly says "If file descriptor 0, 1,
or 2 would otherwise be closed after a successful call to one of the exec
family of functions, implementations may open an unspecified file for the
file descriptor in the new process image. If a standard utility or a
conforming application is executed with file descriptor 0 not open for
reading or with file descriptor 1 or 2 not open for writing, the
environment in which the utility or application is executed shall be
deemed non-conforming, and consequently the utility or application might
not behave as described in this standard.". So at least that description
of the process of creating a new process image only permits opening those
file descriptors but does not require it and indeed explicitly does not
impose requirements on how code behaves if started with those file
descriptors not open.
https://pubs.opengroup.org/onlinepubs/9699919799/functions/execve.html
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2020-08-19 16:28 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-19 12:41 Arsen Arsenović
2020-08-19 16:28 ` Joseph Myers [this message]
2020-08-19 17:46 ` Zack Weinberg
2020-08-19 17:50 ` Joseph Myers
2020-08-19 18:20 ` Adhemerval Zanella
2020-08-19 19:13 ` Florian Weimer
2020-08-19 19:25 ` Adhemerval Zanella
2020-08-19 19:27 ` Florian Weimer
2020-08-19 19:35 ` Adhemerval Zanella
2020-08-19 19:40 ` Arsen Arsenović
2020-08-19 21:04 ` Michael Morrell
2020-08-19 22:32 ` Joseph Myers
2020-08-19 23:45 ` Arsen Arsenović
2020-08-20 22:00 ` Paul Eggert
2020-08-20 23:25 ` Arsen Arsenović
2020-08-27 15:56 ` Zack Weinberg
2020-08-27 18:21 ` Paul Eggert
2020-08-28 0:12 ` Arsen Arsenović
2020-09-04 17:49 ` Arsen Arsenović
2020-09-11 7:47 ` ping^2 " Arsen Arsenović
2020-08-19 23:16 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.21.2008191622010.32578@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=arsen@aarsen.me \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).