On 15/08/2023 19:25, Alejandro Colomar via Std-Proposals wrote:
> 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).
>

Why do you say that?

Fixed-size arrays are great when you know a fixed size. But if you only
know an upper bound, then you might be wasting significant stack space -
and that translates to wasted cache, and slower results. This must be
balanced against any extra code generated to handle a VLA or alloca().

So if the upper bound is known to be small, go for a fixed-size array.
And if the size is fixed (and small enough), then a fixed size array is
definitely better than other options - but in C, remember that some
things that would be fixed size arrays in C++ are technically VLAs in C.
  (Such VLAs with compile-time known size are as efficient as true
fixed-size arrays.)

Fixed-size arrays are also easier to handle for statically generated
stack usage analysis. Static fixed-size arrays are even easier, but if
memory is tight (such as on small embedded systems), the inability to
reuse the memory can be an issue.

malloc() is fine for big allocations, or when you need the allocation to
survive beyond the current scope, but it is /massively/ less efficient
for a simple small local allocation.


Some people argue that alloca() and VLAs are unsafe because there is no
way to get run-time feedback if the sizes are too big and you overflow
the stack - it's straight to UB. But they forget that bad choices of
size for malloc() are equally bad - long before your malloc request is
big enough to be refused, it can be big enough to push your whole system
into slow swap space, or the joys of over-allocation of memory. So any
code using dynamic memory allocation should ensure the size is safe
before allocating - whether it be malloc(), alloca() or VLA's.


What is preferable, is knowing the options, knowing their advantages and
disadvantages, and choosing a solution that is safe, reliable,
maintainable and efficient (and supported by the language you want to
use). There is no universal correct answer.