Date: Tue, 15 Aug 2023 19:41:55 +0300
On 8/14/23 17:31, Alejandro Colomar via Std-Proposals wrote:
> Hello Frederick,
>
> On 2023-08-14 13:44, Frederick Virchanza Gotham via Std-Proposals wrote:
>>
>> And also how about we standardise the function "alloca" which allows
>> us to allocate bytes on the stack? For those not familiar with
>> 'alloca', here's the Linux manual entry:
>>
>> https://man7.org/linux/man-pages/man3/alloca.3.html
>>
>> And here's a quick excerpt from that manual page
>>
>> The alloca() function allocates size bytes of space in the stack
>> frame of the caller. This temporary space is automatically freed
>> when the function that called alloca() returns to its caller.
>> Because it allocates from the stack, it's faster than malloc
>> and free. In certain cases, it can also simplify memory
>> deallocation in applications that use longjmp or siglongjmp.
>
> Now that C has VLAs, alloca(3) is being removed from many projects.
> In most cases, there's no guarantee that the size will fit in the
> stack, and so one should use malloc(3). In the few cases where the
> size is known to be small, VLAs are preferable. In fact, this is
> exactly what glibc is doing at the moment: replace all calls to
> alloca(3) by either malloc(3) or VLAs.
I think the general direction is exactly the opposite - to get rid of
VLAs wherever possible. They are also not supported in C++.
https://www.phoronix.com/news/Linux-Kills-The-VLA
> Hello Frederick,
>
> On 2023-08-14 13:44, Frederick Virchanza Gotham via Std-Proposals wrote:
>>
>> And also how about we standardise the function "alloca" which allows
>> us to allocate bytes on the stack? For those not familiar with
>> 'alloca', here's the Linux manual entry:
>>
>> https://man7.org/linux/man-pages/man3/alloca.3.html
>>
>> And here's a quick excerpt from that manual page
>>
>> The alloca() function allocates size bytes of space in the stack
>> frame of the caller. This temporary space is automatically freed
>> when the function that called alloca() returns to its caller.
>> Because it allocates from the stack, it's faster than malloc
>> and free. In certain cases, it can also simplify memory
>> deallocation in applications that use longjmp or siglongjmp.
>
> Now that C has VLAs, alloca(3) is being removed from many projects.
> In most cases, there's no guarantee that the size will fit in the
> stack, and so one should use malloc(3). In the few cases where the
> size is known to be small, VLAs are preferable. In fact, this is
> exactly what glibc is doing at the moment: replace all calls to
> alloca(3) by either malloc(3) or VLAs.
I think the general direction is exactly the opposite - to get rid of
VLAs wherever possible. They are also not supported in C++.
https://www.phoronix.com/news/Linux-Kills-The-VLA
Received on 2023-08-15 16:42:01