This is the mail archive of the
mailing list for the GCC project.
Re: Replacing malloc with alloca.
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: Jeff Law <law at redhat dot com>
- Cc: Ajit Kumar Agarwal <ajit dot kumar dot agarwal at xilinx dot com>, Richard Biener <richard dot guenther at gmail dot com>, "gcc\ at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Vinod Kathail <vinodk at xilinx dot com>, Shail Aditya Gupta <shailadi at xilinx dot com>, Vidhumouli Hunsigida <vidhum at xilinx dot com>, Nagaraju Mekala <nmekala at xilinx dot com>
- Date: Sun, 13 Sep 2015 21:19:59 +0200
- Subject: Re: Replacing malloc with alloca.
- Authentication-results: sourceware.org; auth=none
- References: <37378DC5BCD0EE48BA4B082E0B55DFAA42990090 at XAP-PVEXMBX02 dot xlnx dot xilinx dot com> <87vbbenpga dot fsf at mid dot deneb dot enyo dot de> <55F5C6E8 dot 5040903 at redhat dot com>
* Jeff Law:
> On 09/13/2015 12:28 PM, Florian Weimer wrote:
>> * Ajit Kumar Agarwal:
>>> The replacement of malloc with alloca can be done on the following
>>> If the lifetime of an object does not stretch beyond the immediate
>>> scope. In such cases the malloc can be replaced with alloca. This
>>> increases the performance to a great extent.
>> You also need to make sure that the object is small (less than a page)
>> and that there is no deep recursion going on. Otherwise, the program
>> may no longer work after the transformation with real-world restricted
>> stack sizes. It may even end up with additional security issues.
> You also have to make sure you're not inside a loop. Even a small
> allocation inside a loop is problematical from a security standpoint.
> You also need to look at what other objects might be on the stack and
> you have to look at the functional scope, not the immediate scope as
> alloca space isn't returned until the end of a function.
Ah, right, alloca is unscoped (except when there are variable-length
Using a VLA might be the better approach (but the size concerns
remain). Introducing VLAs could alter program behavior in case a
pre-existing alloca call, leading to premature deallocation.