From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12451 Path: news.gmane.org!.POSTED!not-for-mail From: Jeff Hammond Newsgroups: gmane.linux.lib.musl.general Subject: Re: Why are stdin/stdout/stderr `FILE *const` in musl? Date: Fri, 2 Feb 2018 08:12:54 -0800 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="94eb2c11bfea5a773705643cfd02" X-Trace: blaine.gmane.org 1517587902 20777 195.159.176.226 (2 Feb 2018 16:11:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 2 Feb 2018 16:11:42 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12467-gllmg-musl=m.gmane.org@lists.openwall.com Fri Feb 02 17:11:38 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 1ehdw2-0004Rb-Is for gllmg-musl@m.gmane.org; Fri, 02 Feb 2018 17:11:30 +0100 Original-Received: (qmail 1751 invoked by uid 550); 2 Feb 2018 16:13:28 -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 1719 invoked from network); 2 Feb 2018 16:13:27 -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=/1A85pmeM7fv7+Kv9NjNSaQurB99ebfLt1A67Ps5t1o=; b=mriLa/Hg6FJLOT21PIcQULA/uv/gwnf8avwofosD5ZHoC7UGLpN4oml6WyGINJXeZ3 PlI1MUOjPXYNE1dgPXTCrEdtvKSt0Pk8zvabHwBsLzXBVqhxIp1hEJax2RHGg/VY+yyu vFeoO/ASblMJv0yREXU7GQOX9vUKJPZL49+1WIlpIz+iK1Pdurl8P/pFr9vIY1Lnlrpc zzzVUbyCWinE+0/oitJhaAPfibdN5Eh2ZEUOiyUW+t3tsZzHmfnstdCVHrveoIrwPzjk 7WNk4BZVpHeM3K6CQuCg1LrJcl/893KnM8+0V0JbHlb1Z8c8f+YHjuyKil4YoBNeyxgn rBkg== 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=/1A85pmeM7fv7+Kv9NjNSaQurB99ebfLt1A67Ps5t1o=; b=jEIR9c+tyCZhlqSnJRZJBA01fDwdzxMbyl7axcXUWgFwI6ZmSXXj38/h5h82jwJHaA MC110jPGOKoXMBCFJkA2URJ0wEr2a8k7T16kS31qqGm+cNDcg5ZAyL2Uj03VhsvztwnM wB/wa0Qs1Jepg8Ptz7KcteDN+PvCi6kYfzFHMZ0qtCFXZ/Ge+sLdxyHTSJYIi+5GZunF vYWTKBbr0N8kCpKd1xr/WQfUcKTgaAXpz6KcIbWS8dtT23due1XIlbjKFlUIpc6W23/P gyae9p53WYd7UVkwu6RbGwU2/jeB6UWk46hkMxUFot0lTQtPYTC3sjfzGXPN8aWEXiHe pG8g== X-Gm-Message-State: AKwxytfknLUsXSDqmqOQ5rB6E3a4/YBohZEOb0+OXy1bWZ35lKQU0+GW Ic4UWAQvkcMfVIPM4Nq1RB2pInhReo6l4VYJ/g6Reg== X-Google-Smtp-Source: AH8x224hFNZCDPohj4dt8qOJtJTs8kng/DBEwsCBG01vEWZoVaoKchR0GUr4aehFszfKsn3WnFyFnzPiOSXe187Kad4= X-Received: by 10.98.134.206 with SMTP id x197mr28961896pfd.82.1517587994931; Fri, 02 Feb 2018 08:13:14 -0800 (PST) In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:12451 Archived-At: --94eb2c11bfea5a773705643cfd02 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 2, 2018 at 7:30 AM, CodingMarkus wrote: > 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/dyna > miclibrary-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 kn= ow the C > standard better than I probably ever will. > I seriously doubt that they would describe themselves as infallible. In this specific case, the patch was submitted by a JuliaLang developer who is an expert in LLVM but probably not ISO C. The appropriate action here is not to assume they know everything but to file a bug report. > 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 = because 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 b= e > present (they don=E2=80=99t have to, they are non-standard) or to be pres= ent as > real functions. In musl they are present but they are defines (tfeeko64 i= s > a define to fseek and so on) and this is unexpected but I see no reason w= hy > 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 retde= c > bases on an older one). > > I=E2=80=99m only worried with how interchangeable musl is as a standard l= ibc > 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. > Programming standards and the associated expectation of compatibility are aspirational. Your argument that 9/10 must be right is a variant of "tyranny of the majority". This is not how standards compliance works. A compliant implementation is compliant, even if there are a million non-compliant implementations. 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 (regardl= ess if > it=E2=80=99s syntactically correct) or whether musl should define stdX th= e same way > all the other libraries are doing it. > LLVM is using incorrect code that is broken and needs to be fixed if the LLVM developers want their implementation to be portable to faithful implementations of the C/POSIX library standard. Jeff --=20 Jeff Hammond jeff.science@gmail.com http://jeffhammond.github.io/ --94eb2c11bfea5a773705643cfd02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Feb 2, 2018 at 7:30 AM, CodingMarkus <CodingMarkus@ha= nauska.name> wrote:
=C2=A0
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.

I seriously doubt that they would describe themselves as infallible.=C2= =A0 In this specific case, the patch was submitted by a JuliaLang developer= who is an expert in LLVM but probably not ISO C.

= The appropriate action here is not to assume they know everything but to fi= le a bug report.
=C2=A0
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.

Programming standards and th= e associated expectation of compatibility are aspirational.

<= /div>
Your argument that 9/10 must be right is a variant of "tyran= ny of the majority".=C2=A0 This is not how standards compliance works.= =C2=A0 A compliant implementation is compliant, even if there are a million= non-compliant implementations.

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.

=
LLVM is using incorrect code that is broken and needs to be fixe= d if the LLVM developers want their implementation to be portable to faithf= ul implementations of the C/POSIX library standard.

Jeff

--
Jeff Hammond
jeff.science@gmail.co= m
http:/= /jeffhammond.github.io/
--94eb2c11bfea5a773705643cfd02--