From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12453 Path: news.gmane.org!.POSTED!not-for-mail From: William Pitcock Newsgroups: gmane.linux.lib.musl.general Subject: Re: Why are stdin/stdout/stderr `FILE *const` in musl? Date: Fri, 2 Feb 2018 11:16:32 -0600 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: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1517591704 23482 195.159.176.226 (2 Feb 2018 17:15:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 2 Feb 2018 17:15:04 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12469-gllmg-musl=m.gmane.org@lists.openwall.com Fri Feb 02 18:15:00 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 1ehevF-0004yp-PB for gllmg-musl@m.gmane.org; Fri, 02 Feb 2018 18:14:45 +0100 Original-Received: (qmail 5747 invoked by uid 550); 2 Feb 2018 17:16:46 -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 5713 invoked from network); 2 Feb 2018 17:16:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dereferenced-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=cGuQZiNZURFmvcprQ7v1//kAD3w1AQgiDNb1pEZ/EqA=; b=FBEJX5v+7vK1923BwJ2XeCk8xgTiErbHohnsZ8N9O4xVjIU2ASaEsJWmI36/vZj3ao 691cwzDzngEujwYl7DIUEsvxLZnG7PzMF+Ed+0pspNQkgg4JgyptWeDfIZ2irxcf06g9 Qbx44+w6nY8+KgCFlf4OoDt3MzFUpnNb4EEMezjZNQZEq1PQcDvANDAc0PKHJ339dwou hkjF1+c7+f1CGbji6OKWNZofyujDD0mH4t8sOHZYOkvQ8eOOnD+BcgTV2BAdmh0lDv3K 2VuzyTJhLzFadUddcQZ5LmNVGV6KGdzzeFxPlyzIhN+OZ1UqkwnxUbyKwqup4izEDcEm ZLXQ== 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:content-transfer-encoding; bh=cGuQZiNZURFmvcprQ7v1//kAD3w1AQgiDNb1pEZ/EqA=; b=IoeR55FB4i14MFENugmqrWpBHX1VrbnivfiPduQ7isnRte1L2GRWKWeTvpO8N+1ZOy zM8432ZXYjMlLi6Y5UvvzR6tn3GbPKiC8t1mse/5ZvjiPxo+YFgHdHq7KX1LP2PTu/nT WbG8I4kI+d9a1kL+8z0JPNt/CV12g8eZBTkBeaXDL+/eGcKzHdSlB3VEhTHLxTOIiqwY D1b2cJ3b4GiIjK1f/yItG0lN1hwR8EkfzQv6GevX9/LgWL6twQN86lpmFe/FhyKXb+PE hOqwgxxraAbwV08HftTs8DIuPCkrDDovg1ePuXnR7wx26CusO4dWtqryfIyLcRfrgwqa UxTw== X-Gm-Message-State: AKwxytcp6LcPrpA2ChceRq/s+hrKeBTXNxOIsnpDE8gC5MalQq25TEyM iIhFzuVpNvR9nHtqMNRtIDMjCwPNyi9EFCNuWxIjrw== X-Google-Smtp-Source: AH8x226O3zTsz++qWu/UE54S7HG+YJ5etDk/5T03SANPmo0RAhwa4WPen8espOF20VfwidXA6MsSeBQDlXIRcMDqgWE= X-Received: by 10.200.26.130 with SMTP id x2mr68906792qtj.288.1517591793169; Fri, 02 Feb 2018 09:16:33 -0800 (PST) In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:12453 Archived-At: Hi, On Fri, Feb 2, 2018 at 9:30 AM, CodingMarkus w= rote: >> On 2018-02-02, at 16:01, Markus Wichmann wrote: >> >> Why would you ever need a pointer to stdout or stderr? What he wants is a pointer to the pointer itself. > "Why would you ever need" is no valid argument. It=E2=80=99s no argument = for 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 si= mply no argument because it doesn=E2=80=99t matter why the person who bough= t the toolset wants a green wall or whether it=E2=80=99s a good idea to pai= nt walls in green. This is a meta discusion that misses the actual point wh= ich 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-fi= x-build-musl.patch?id=3DHEAD > > And that the people who themselves makes the currently second most succes= sful 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. Actually, that patch should not be necessary soon, thankfully. Also stdin/stdout/stderr and many other objects provided by the libc should never ever be considered explicit symbols. Only ISO C functions should be considered explicit symbols. But overall, the EXPLICIT_SYMBOL() stuff in LLVM is a massive hackjob and needs to just be completely removed. > 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 b= ecause of musl: > > https://github.com/avast-tl/retdec > > Even with that patch it cannot be built but that has other reasons and th= is 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 pre= sent (they don=E2=80=99t have to, they are non-standard) or to be present a= s 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 fo= r 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, the= n they should always be interchangeable and all code building with one of t= hem 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 o= f 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. A lot of libcs are derived in part from the historical BSD libc (including the GNU one etc). Thusly, it is possible that these libc have a design that is informed by the state of the 1980s instead of modern practice. It does not mean that any of the implementations are doing it wrong. > 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. It shouldn't, there are advantages to the current way it is done. Anything that catches technically incorrect code is a major win from security and overall robustness points of view. William