Hi Andrey,

On 2023-08-15 18:41, Andrey Semashev via Std-Proposals wrote:
> 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++.

Hmm, I've revisited the thread I was remembering[1], and yeah, they're
replacing alloca(3) by a fixed-size array. I was remembering wrong.

Yeah, fixed-size arrays or malloc(3) should be preferable to alloca(3).

Cheers,
Alex

[1]: <https://inbox.sourceware.org/libc-alpha/20230705185835.1474212-1-josimmon_at_[hidden]/T/#u>

>
> https://www.phoronix.com/news/Linux-Kills-The-VLA
>