This is the mail archive of the
mailing list for the glibc project.
Re: why Glibc does not build with clang?
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 23 May 2014 14:40:19 -0700 (PDT)
- Subject: Re: why Glibc does not build with clang?
- Authentication-results: sourceware.org; auth=none
- References: <CAGQ9bdw135gBO+cTQx3Ws1GrRgFsi8-j=Y_mZ=ixebpPzB4gXw at mail dot gmail dot com>
The general answer is that the GNU C Library is implemented in GNU C,
not in ISO C. We use GNU extensions freely whenever they lead to
cleaner, more readable, more maintainable, and/or more performant
code. It is fundamentally wrong to think that rewriting code to avoid
GNU C extensions is "cleanup" by definition.
It will never be a priority for the project to support compiling libc
with non-GNU compilers. (This issue is entirely separate from the use
of libc's installed headers with non-GNU compilers.) We will never
consider it a blocking bug (or perhaps, any kind of bug at all) if
there is a regression in compilability with non-GNU compilers while
there is no compilability regression with GNU compilers of the
versions we document supporting.
So, "building with clang" is not going to be something that we as a
project worry about. If people like you volunteer the time to improve
such things, that's of course up to you. There is no philosophical or
political reason why we'd reject changes out of hand--but nor is there
any such general reason why we'd let your goals trump our priorities.
General friendliness will lead us to put a little effort into helping
you succeed in whatever you're doing when it doesn't do us harm.
We accept or reject individual changes on their own local merits.
There are often competing interests that trade off in deciding to
accept or reject a change. Supporting building with non-GNU compilers
will always be a very weak competitor in such contests. So if a
change motivated by supporting non-GNU compilers otherwise does harm
to the readability, maintainability, or performance of libc's code, we
will not accept it. If it improves the status quo on these factors or
is insignificant to them, we are quite likely to accept it. Every
determination will be made on an individual case, never on blanket
notions like "don't use GNU C feature X" or "make it build with
non-GNU compiler Y".
On specific GNU C features, the details vary by the feature and by the
individual use. As you can tell from reading this mailing list,
opinions vary among the maintainers and most active contributors as to
the readability and maintainability effects of various particular
features in particular kinds of uses. As with everything, we'll talk
through each case and reach a consensus in line with the project's
general principles (and GNU's) as I've just described.
VLAIS is something that I suspect has rarely if ever been exploited
intentionally in our code. Off hand it seems likely that people will
like each change that avoids an individual case of VLAIS. Send each
such change individually and see what you get. (When changes are not
actually interdependent, I think it's actually anti-useful to identify
them as part of a series. It makes people think they need to review
the whole series together, which slows things down. The kinds of
changes you are interested in are likely to be almost entirely
isolated individual cases without interdependencies. So send each one
in isolation and you'll get quicker piecemeal feedback and
Nested functions are a very different story. They are a powerful tool
to improve readability and maintainability, and we'll use them
whenever doing so gives us the most concise and maintainable code.
Opinions will vary about whether that is or isn't the case for a
particular instance. As rules of thumb: if the patch is large (aside
from trivialities like indentation changes), or results in a lot more
typing of parameters to pass context around, it's more likely to be
rejected; if you found the status quo ante harder to understand
because the interface contract of the internal function was less clear
due to willy-nilly use of the parent function's locals, and your patch
makes it much easier to understand the code, then it's more likely to
be accepted; if it materially affects the quality of the code
generated by recent GCC versions either for good or for ill, that is
likely to sway our reactions in scale roughly comparable to the
aesthetic questions (it never hurts your case to point out that it
made no appreciable difference to the generated code).