This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: why Glibc does use alloca?
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Jeff Law <law at redhat dot com>, OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Florian Weimer <fweimer at redhat dot com>, Will Newton <will dot newton at linaro dot org>, Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 20 May 2014 16:59:01 -0400
- Subject: Re: why Glibc does use alloca?
- Authentication-results: sourceware.org; auth=none
- References: <CAGQ9bdw135gBO+cTQx3Ws1GrRgFsi8-j=Y_mZ=ixebpPzB4gXw at mail dot gmail dot com> <53760025 dot 10204 at redhat dot com> <CANu=DmhF=PZBVHtOPw5ZMCHjcy6vqdCvrRvY+xO9hzfkjTCRQA at mail dot gmail dot com> <53760826 dot 6090203 at redhat dot com> <20140516135304 dot GA29829 at domone dot podge> <537630BB dot 7030701 at redhat dot com> <20140516160903 dot GA2363 at domone dot podge> <537638BC dot 4090500 at redhat dot com>
On 05/16/2014 12:11 PM, Jeff Law wrote:
>> There is additional dull knife risk. If alloca is not available then
>> users that want performance will replace it with 64k arrays and malloc
>> fallback which makes overflow more likely.
> I'd hope patch review would catch this kind of sillyness.
I believe Ondrej is talking about user applications. Even if glibc were
fixed, and we banned alloca everywhere, users would simply start using
large arrays to optimize their code. What we really want is alloca with
some light instrumentation and checking. Sure we can ban it in glibc, but
that's just the tip of the iceberg.
Does that make sense?
Cheers,
Carlos.