From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12449 Path: news.gmane.org!.POSTED!not-for-mail From: Jon Chesterfield Newsgroups: gmane.linux.lib.musl.general Subject: Re: Why are stdin/stdout/stderr `FILE *const` in musl? Date: Fri, 2 Feb 2018 15:53:33 +0000 Message-ID: References: <1E109BA9-57C0-42DB-9B43-8ADE27F9E76C@hanauska.name> <20180202150132.tzocezrj5vskos66@voyager> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a11c17f4401e43305643cb7f9" X-Trace: blaine.gmane.org 1517586717 20468 195.159.176.226 (2 Feb 2018 15:51:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 2 Feb 2018 15:51:57 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12465-gllmg-musl=m.gmane.org@lists.openwall.com Fri Feb 02 16:51:53 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1ehdcv-0004b9-Td for gllmg-musl@m.gmane.org; Fri, 02 Feb 2018 16:51:46 +0100 Original-Received: (qmail 7608 invoked by uid 550); 2 Feb 2018 15:53:48 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 7586 invoked from network); 2 Feb 2018 15:53:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=vNEhjlNr2On3a9RrvQx39QD7B/lDsXfCQBj6SycJ0fw=; b=sUKYBB5kXR+kbChD/6lwCS70B91t1knm1x1T4AwuHacAzpVwfIUIHm+jn8ZrjbG3yk GsEnmZ/866LFK+BwjZOxyfwq+N/Y/2Epm7rcEzauAhk/cShXWQ7Bf6o/yDOWos69qz0W MdoOYpIfLrvgB3lrF2coE5bIqfwDu06PrMPe3htTZMgfHGc+vgEQlB/L87QIdAYImPnC nK8JXqltFr12jeGgHJ5gPTTMnImR9qIV3UcftrjNHh9mGsmfmoRypn0kYmwslkBbPbaR Q8+J4OJWLUFei1xHZpoTYJegivwAPOV9vK/VolUUphkJIR3C8ooHr+uF3/CWjByykWaQ vuxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=vNEhjlNr2On3a9RrvQx39QD7B/lDsXfCQBj6SycJ0fw=; b=nMUQhueDSPah7K6tAvFoxUJcG7bB0DEIvnA4Hq0iLRHdsgeMpEIebcbIZj+xEmstTx UTE1bFWmkBROAAdIkjNNjfBYTmUCkyHCymIkiv+R1FL00MuH5Hu/E2i0Ss8wi3/JuFle NQKRAXu50r3CAuc5c+sohiQbhbnMd06gQvhimcOYt2JMLb/fQQmZVmoL27FNq6+6inou vXc0cPbjRVtJoYqY0nbHdAiKMqJEqFxXSXWxuYECTZv+SAxBGtaXwd0q1+2Senmvch2J bZxKcRwJqB4H8bNkE/BBNjOp6J4Gi632po127EndLf5nVTn9D6sSZuL5rTTyIa9etlb6 J+Lg== X-Gm-Message-State: AKwxytef+ZCjytDbrazf2zjHs777ausEVyoVjN4S/XzQVMAZKfQinM0x sXdFjWUGm0QSvANJphY5v1NDLJT7CqI2NRQ7ujRdTw== X-Google-Smtp-Source: AH8x227g+7+FvqwCkmSZMrsBE0KgznGFlPCIbtT/dPvQVuRfI9jE1vmWRO5EoPMUga7W1kcw+WrdsVkZqvk4GyDCHtY= X-Received: by 10.202.244.72 with SMTP id s69mr13698148oih.318.1517586814721; Fri, 02 Feb 2018 07:53:34 -0800 (PST) In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:12449 Archived-At: --001a11c17f4401e43305643cb7f9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think compiler engineers are among those most likely to ignore parts of the standard they don't agree with. We're not a good choice for an appeal to authority in this instance. On 2 Feb 2018 16:30, "CodingMarkus" wrote: > On 2018-02-02, at 16:01, Markus Wichmann wrote: > > Why would you ever need a pointer to stdout or stderr? "Why would you ever need" is no valid argument. It=E2=80=99s no argument fo= r anything and especially never an argument against anything. If I buy a toolset to paint my wall and I cannot use it to paint it green, then =E2=80=9Cwhy would you ever want to have a green wall=E2=80=9D is simp= ly no argument because it doesn=E2=80=99t matter why the person who bought the toolset wan= ts a green wall or whether it=E2=80=99s a good idea to paint walls in green. Thi= s is a meta discusion that misses the actual point which is that the toolset won= =E2=80=99t allow me to paint my wall green. Here is a real life code sample that breaks exactly because the reason I was pointing out, so apparently clang developers like green walls: https://git.alpinelinux.org/cgit/aports/tree/main/llvm5/ dynamiclibrary-fix-build-musl.patch?id=3DHEAD And that the people who themselves makes the currently second most successful open source compiler on the market act outside the C standard doesn=E2=80=99t sound very convincing to me. If in doubt, these people know= the C standard better than I probably ever will. And, of course, this affects other projects based on LLVM infrastructure, e.g. this one, which simply cannot be built on Alpine and that=E2=80=99s be= cause of musl: https://github.com/avast-tl/retdec Even with that patch it cannot be built but that has other reasons and this time the problem is not a question related to any specs or standards but to the fact that LLVM expects functions like fseeko64 to either not be present (they don=E2=80=99t have to, they are non-standard) or to be present as rea= l functions. In musl they are present but they are defines (tfeeko64 is a define to fseek and so on) and this is unexpected but I see no reason why it would not be allowed so here I can blame LLVM. There is also a fix for that BTW and the latest LLVM versions contain that fix already (but retdec bases on an older one). I=E2=80=99m only worried with how interchangeable musl is as a standard lib= c because the idea of a standard is that it guarantees compatibility. If there are ten libc libraries and they all conform to the same standard, then they should always be interchangeable and all code building with one of them should also build with the other nine. Every time this is not the case, there is a problem that needs to be fixed IMHO. In that case either nine of them are doing it right and one of them is doing it wrong or nine of them are doing it wrong and one of them is doing it right, well, guess what is more likely. So in the end, the question is whether LLVM is using incorrect code here that simply doesn=E2=80=99t need to compile because it is broken (regardles= s if it=E2=80=99s syntactically correct) or whether musl should define stdX the = same way all the other libraries are doing it. Regards, Markus --001a11c17f4401e43305643cb7f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think compiler engineers are among those most like= ly to ignore parts of the standard they don't agree with. We're not= a good choice for an appeal to authority in this instance.

On 2 Feb 2018 16:30, "CodingMarkus"= <CodingMarkus@hanauska.na= me> 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=E2=80=99= s no argument for anything and especially never an argument against anythin= g.

If I buy a toolset to paint my wall and I cannot use it to paint it green, = then =E2=80=9Cwhy would you ever want to have a green wall=E2=80=9D is simp= ly no argument because it doesn=E2=80=99t matter why the person who bought = the toolset wants a green wall or whether it=E2=80=99s a good idea to paint= walls in green. This is a meta discusion that misses the actual point whic= h is that the toolset won=E2=80=99t allow me to paint my wall green.

Here is a real life code sample that breaks exactly because the reason I wa= s pointing out, so apparently clang developers like green walls:

https://git.alpinelinux.org/cgit/aports/tree/main/llvm5/dynamicl= ibrary-fix-build-musl.patch?id=3DHEAD

And that the people who themselves makes the currently second most successf= ul open source compiler on the market act outside the C standard doesn=E2= =80=99t sound very convincing to me. If in doubt, these people know the C s= tandard better than I probably ever will.

And, of course, this affects other projects based on LLVM infrastructure, e= .g. this one, which simply cannot be built on Alpine and that=E2=80=99s bec= ause of musl:

https://github.com/avast-tl/retdec

Even with that patch it cannot be built but that has other reasons and this= time the problem is not a question related to any specs or standards but t= o the fact that LLVM expects functions like fseeko64 to either not be prese= nt (they don=E2=80=99t have to, they are non-standard) or to be present as = real functions. In musl they are present but they are defines (tfeeko64 is = a define to fseek and so on) and this is unexpected but I see no reason why= it would not be allowed so here I can blame LLVM. There is also a fix for = that BTW and the latest LLVM versions contain that fix already (but retdec = bases on an older one).

I=E2=80=99m only worried with how interchangeable musl is as a standard lib= c because the idea of a standard is that it guarantees compatibility. If th= ere are ten libc libraries and they all conform to the same standard, then = they should always be interchangeable and all code building with one of the= m should also build with the other nine. Every time this is not the case, t= here is a problem that needs to be fixed IMHO. In that case either nine of = them are doing it right and one of them is doing it wrong or nine of them a= re doing it wrong and one of them is doing it right, well, guess what is mo= re likely.

So in the end, the question is whether LLVM is using incorrect code here th= at simply doesn=E2=80=99t need to compile because it is broken (regardless = if it=E2=80=99s syntactically correct) or whether musl should define stdX t= he same way all the other libraries are doing it.

Regards,
Markus

--001a11c17f4401e43305643cb7f9--