mailing list of musl libc
 help / color / mirror / code / Atom feed
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 17:01:07 +0100	[thread overview]
Message-ID: <20180202170107.2df62fe5@inria.fr> (raw)
In-Reply-To: <F4D34AB3-372B-4A13-AD89-D80F7E07E757@hanauska.name>

[-- Attachment #1: Type: text/plain, Size: 2508 bytes --]

Hello,

On Fri, 2 Feb 2018 16:30:03 +0100 CodingMarkus
<CodingMarkus@hanauska.name> wrote:

> > On 2018-02-02, at 16:01, Markus Wichmann <nullplan@gmx.net> wrote:
> > 
> > Why would you ever need a pointer to stdout or stderr?  
> 
> 
> "Why would you ever need" is no valid argument. It’s no argument for
> anything and especially never an argument against anything.

No, but the exact definition that I gave you from the standard, is
certainly an argument. Did you see this? I didn't see a reply from you
to this.

I checked the provision that this is an expression is there at least
since C99.

> https://git.alpinelinux.org/cgit/aports/tree/main/llvm5/dynamiclibrary-fix-build-musl.patch?id=HEAD

What this shows is that they are clearly wrong in doing

EXPLICIT_SYMBOL(stderr);

stderr is *not* an explicit symbol and should not be.

> And that the people who themselves makes the currently second most
> successful open source compiler on the market act outside the C
> standard doesn’t sound very convincing to me. If in doubt, these
> people know the C standard better than I probably ever will.

Some of them certainly do.

I hope that you are not suggesting that the people that replied to you
here on that list don't know the C standard at least as good.

> I’m only worried with how interchangeable musl is as a standard libc
> because the idea of a standard is that it guarantees compatibility.

exactly, so what they are doing is to be frowned upon

(In particular, because this is a compiler framework that is making
assumptions about the library framework that is not justified.)

> If there are ten libc libraries and they all conform to the same
> standard,

As said in my other mail, this is undefined behavior LaLaLand. So
implementors can do what they want, they don't even have to document
it. But it is just not portable.

Now, if you are claiming that this would be an important feature, one
could certainly at least discuss it. But what I heard so far from you
was only reference to authority (llvm must know what they are doing).
You were not arguing why they are doing this and why this would be
important.

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 --]

  parent reply	other threads:[~2018-02-02 16:01 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
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 [this message]
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=20180202170107.2df62fe5@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).