This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: why Glibc does not build with clang?
- From: Rich Felker <dalias at libc dot org>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Sat, 24 May 2014 10:29:02 -0400
- 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> <20140523214019 dot DA9FF2C3975 at topped-with-meat dot com>
On Fri, May 23, 2014 at 02:40:19PM -0700, Roland McGrath wrote:
> 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.
Never is a strong word. What if we got to the point where GCC was
utterly unmaintained, or where other compilers were producing code
that was 15-20% faster than what GCC produced in performance-crticial
code paths? Or what if it becomes desirable to use glibc on targets
(virtual machine type things, etc.) not supported by GCC? I think
refusing to support other compilers is a very backwards decision.
It also comes across as petty and political.
> VLAIS is something that I suspect has rarely if ever been exploited
> intentionally in our code.
I'd question assumptions like that.
> 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
This is perfectly reasonable.
> 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.
I disagree. Nested functions are a feature that fundamentally requires
producing an insecure executable/library (executable-stack flag)
_except_ in cases where the compiler optimizes out that need. So if
you use nested functions, you're relying on the optimizer to do what
you expect in order to satisfy a security contract. This is
fundamentally bad security design.
As such, I think clang is totally correct to omit this misfeature and
attempt to deprecate its use. And glibc should follow.
Rich