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.