From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12448 Path: news.gmane.org!.POSTED!not-for-mail From: CodingMarkus Newsgroups: gmane.linux.lib.musl.general Subject: Re: Why are stdin/stdout/stderr `FILE *const` in musl? Date: Fri, 2 Feb 2018 16:30:03 +0100 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 (Mac OS X Mail 11.2 \(3445.5.20\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1517585321 4194 195.159.176.226 (2 Feb 2018 15:28:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 2 Feb 2018 15:28:41 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12464-gllmg-musl=m.gmane.org@lists.openwall.com Fri Feb 02 16:28:36 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 1ehdGA-0007ti-Qs for gllmg-musl@m.gmane.org; Fri, 02 Feb 2018 16:28:14 +0100 Original-Received: (qmail 13485 invoked by uid 550); 2 Feb 2018 15:30:17 -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 13467 invoked from network); 2 Feb 2018 15:30:17 -0000 X-Virus-Scanned: amavisd-new at heinlein-support.de In-Reply-To: <20180202150132.tzocezrj5vskos66@voyager> Xref: news.gmane.org gmane.linux.lib.musl.general:12448 Archived-At: > On 2018-02-02, at 16:01, Markus Wichmann wrote: >=20 > 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 = for anything and especially never an argument against anything.=20 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 simply 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 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 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 be present (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 = libc 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 = (regardless 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=