This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: alloca vs malloc
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Jeff Law <law at redhat dot com>
- Cc: Rich Felker <dalias at libc dot org>, 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: Sat, 17 May 2014 01:20:39 +0200
- Subject: Re: alloca vs malloc
- 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> <20140516190504 dot GF507 at brightrain dot aerifal dot cx> <20140516203140 dot GA16889 at domone dot podge> <53768528 dot 1020502 at redhat dot com>
On Fri, May 16, 2014 at 03:37:44PM -0600, Jeff Law wrote:
> On 05/16/14 14:31, OndÅej BÃlka wrote:
> >
> >>Moreover, turning alloca failures into "reliable crashes" is not a
> >>solution. If an operation requires allocation which could fail, it
> >>must be able to back out whatever work it already did and report
> >>failure. Crashing is not an acceptable implementation.
> >>
> >No, when it is third party codebase and it does not want to rewrite
> >existing code do you have a better proposal?
> alloca is typically going to be expanded inline by the compiler.
> Calls from a 3rd party library into any glibc implementation of
> alloca should be rare enough that they're a "don't care"
> situation...
>
> And to be clear, when I want to ban alloca, I'm referring to uses
> within glibc itself.
>
I did not talked about glibc alloca but alloca in general.
For libc there are better alternatives, I will add priority to malloca
cleanup. As glibc code is now alloca are mostly
trivial or following this pattern occuring about hundred times:
else if (__libc_use_alloca (len * sizeof (wchar_t)))
string = (CHAR_T *) alloca (len * sizeof (wchar_t));
else if ((string = (CHAR_T *) malloc (len * sizeof (wchar_t)))
== NULL)
{
done = -1;
goto all_done;
}
else
string_malloced = 1;
Then there are extend_alloca patterns.
As now a risk of manually rewriting alloca could introduce bugs and
decrease performance so it is unlikely a improvement.