This is the mail archive of the
mailing list for the glibc project.
Re: alloca vs malloc
- From: Jeff Law <law at redhat dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>, Rich Felker <dalias at libc dot org>
- 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: Fri, 16 May 2014 15:37:44 -0600
- 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>
On 05/16/14 14:31, OndÅej BÃlka wrote:
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...
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?
And to be clear, when I want to ban alloca, I'm referring to uses within