[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 2 Feb 2018 08:12:54 -0800
From: Jeff Hammond <jeff.science@...il.com>
To: musl@...ts.openwall.com
Subject: Re: Why are stdin/stdout/stderr `FILE *const` in musl?
On Fri, Feb 2, 2018 at 7:30 AM, CodingMarkus <CodingMarkus@...auska.name>
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=HEAD
>
> 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.
>
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’s 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’t 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’m 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.
>
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’t need to compile because it is broken (regardless if
> it’s syntactically correct) or whether musl should define stdX the 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
--
Jeff Hammond
jeff.science@...il.com
http://jeffhammond.github.io/
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
