Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 2 Feb 2018 08:12:54 -0800
From: Jeff Hammond <>
Subject: Re: Why are stdin/stdout/stderr `FILE *const` in musl?

On Fri, Feb 2, 2018 at 7:30 AM, CodingMarkus <>

> Here is a real life code sample that breaks exactly because the reason I
> was pointing out, so apparently clang developers like green walls:
> 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:
> 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

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

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 Hammond

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.