This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: why Glibc does not build with clang?

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]