Re: Why are stdin/stdout/stderr `FILE *const` in musl?

[Jon Chesterfield <jonathanchesterfield@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3202 bytes --]

I think compiler engineers are among those most likely to ignore parts of
the standard they don't agree with. We're not a good choice for an appeal
to authority in this instance.

On 2 Feb 2018 16:30, "CodingMarkus" <CodingMarkus@hanauska.name> wrote:



> On 2018-02-02, at 16:01, Markus Wichmann <nullplan@gmx.net> wrote:
>
> Why would you ever need a pointer to stdout or stderr?


"Why would you ever need" is no valid argument. It’s 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 “why would you ever want to have a green wall” is simply no argument
because it doesn’t matter why the person who bought the toolset wants a
green wall or whether it’s a good idea to paint walls in green. This is a
meta discusion that misses the actual point which is that the toolset won’t
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=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.

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.

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.

Regards,
Markus

[-- Attachment #2: Type: text/html, Size: 3976 bytes --]