From: Jens Gustedt <jens.gustedt@inria.fr>
To: CodingMarkus <CodingMarkus@hanauska.name>
Cc: musl@lists.openwall.com
Subject: Re: Why are stdin/stdout/stderr `FILE *const` in musl?
Date: Fri, 2 Feb 2018 14:54:27 +0100 [thread overview]
Message-ID: <20180202145427.11f0c0b0@inria.fr> (raw)
In-Reply-To: <1E109BA9-57C0-42DB-9B43-8ADE27F9E76C@hanauska.name>
[-- Attachment #1: Type: text/plain, Size: 1994 bytes --]
Hello CodingMarkus,
On Fri, 2 Feb 2018 14:24:28 +0100 CodingMarkus
<CodingMarkus@hanauska.name> wrote:
> Hello everyone!
>
> Just a quick question:
> Why does musl define stdin, stdout, and stderr to be of type `FILE
> *const`? Neither the C standard, nor the POSIX standard require,
> recommend or even imply that it would be allowed that this is a
> `const` pointer. That’s why other C libraries define it as `FILE *`
> only because that matches the examples given by POSIX and that
> matches the description found in any ISO-C standard.
I don't think so. The C standard says
> stderr
> stdin
> stdout
> which are expressions of type "pointer to FILE" that point to the FILE objects associated, respectively,
which clearly states that these are "expressions" not lvalues, and so
your code
> void * getOutputPtr ( void ) {
> if (/* whatever */) {
> return &stdout;
> }
> return &stderr;
> }
is not conforming. In is undefined (by omission of defining it) to
take the address of such an expression.
(This is different from errno, e.g, which is defined as a modifiable
lvalue.)
> and it is correct by POSIX
> standard but it won’t compile with strict compiler settings when
> using musl as the compiler complains that the `const` is lost and
> there is no explicitly cast for that.
> error: cannot initialize return object of type 'void *' with
> an rvalue of type 'FILE *const *'
and this is a feature, because it points to where your program has
undefined behavior.
The C standard has freopen for the cases that you want to change the
association or the access mode of one of the standard streams.
Jens
--
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
next prev parent reply other threads:[~2018-02-02 13:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-02 13:24 CodingMarkus
2018-02-02 13:54 ` Jens Gustedt [this message]
2018-02-02 14:13 ` Alexander Monakov
2018-02-02 15:01 ` Markus Wichmann
2018-02-02 15:30 ` CodingMarkus
[not found] ` <CAOUYtQAWqEY_Ys3crsyXDmVVqJVjfzwTA0NsDxfpgU5cP_t2nA@mail.gmail.com>
2018-02-02 15:53 ` Jon Chesterfield
2018-02-02 16:01 ` Jens Gustedt
2018-02-02 16:12 ` Jeff Hammond
2018-02-02 17:16 ` William Pitcock
2018-02-02 17:35 ` 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=20180202145427.11f0c0b0@inria.fr \
--to=jens.gustedt@inria.fr \
--cc=CodingMarkus@hanauska.name \
--cc=musl@lists.openwall.com \
/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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
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 NNTP newsgroup(s).