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 Sat, May 24, 2014 at 01:54:03PM -0400, David Miller wrote:
> From: Rich Felker <>
> Date: Sat, 24 May 2014 10:51:39 -0400
> > On Sat, May 24, 2014 at 04:46:03PM +0200, Andreas Schwab wrote:
> >> Rich Felker <> writes:
> >> 
> >> > Nested functions are a feature that fundamentally requires producing
> >> > an insecure executable/library (executable-stack flag)
> >> 
> >> Only if you pass the address of it out of the containing function.
> > 
> > That's my "_except_ in cases where the compiler optimizes out that
> > need." I'm quite aware that in the current usage cases in glibc, with
> > current compiler optimizations, the need is optimized out. What I
> > object to is relying on this optimization to satisfy a security
> > contract.
> > 
> > BTW one could imagine "reasonable" uses where the address gets "passed
> > out" of the containing function to another small static function; in
> > such cases, whether the resulting code requires executable stack, even
> > with current compilers, likely depends on the level of inlining and
> > inter-procedural optimization.
> GCC makes this decision at the code generation phase, long before
> any optimization passes are run, last time I checked.

I consider this an implementation detail. *Conceptually*, in the
general case, nested functions require trampolines or a function
pointer representation that includes a hidden data pointer, and
special-casing certain uses is, conceptually, an optimization,
regardless of where the special-casing takes place in the

> I believe that a lot of people reading this thread see your arguments
> as quite a stretch at this point.

Yes, and it's getting pointless to argue over it. I consider nested
functions fundamentally wrong and harmful and I've explained the
reasons. If others disagree, there's nothing really left to discuss
and we should just drop the topic.


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