On Fri, Feb 2, 2018 at 7:30 AM, CodingMarkus <CodingMarkus@hanauska.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@gmail.com
http://jeffhammond.github.io/