This is the mail archive of the libc-alpha@sourceware.org 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 <dalias@libc.org>
> Date: Sat, 24 May 2014 10:51:39 -0400
> 
> > On Sat, May 24, 2014 at 04:46:03PM +0200, Andreas Schwab wrote:
> >> Rich Felker <dalias@libc.org> 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
implementation.

> 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.

Rich


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