Le 21/07/2021 à 21:08, Andreas Messer a écrit :
> On Wed, Jul 21, 2021 at 02:36:16PM +0200, Didier Kryn wrote:
>> added (by gcc ?) to work around a missing feature of the C language:
>> dynamic allocation on the stack. This lack has disapeared many years ago
>> ( don't know with which version of the C standard) , with the following
>> form of allocation:
>>
>> ...
>>
>> n = 2x+1;
>>
>> {
>>
>>     int array[n];
>>
>>     ...
>>
>> }
>>
>>     And, therefore, alloca() should be removed.
> Well, alloca(n*sizeof(int)) and your suggestion both do the same in that
> they allocate memory from stack without any checking. Thus both will
> show the same failure mode of possible stack overflow.

    There's a choice of options in GCC to deal with stack protection.
Eg:  -fstack-check

    Plus a bunch of macros.

    They all deal with allocation of automatic variables. For alloca(),
instead, there's explicitely no check.

    In addition, the compiler is not informed of the invocation of
alloca(); therefore the space allocated to non-static automatic
variables may overlap with the space "allocated" by alloca().

>
> In any case, the implementation should put some limit on n before
> executing alloca() or int array[n].
>
> To be honest, I really don't seesomething against using alloca() despite
> its not Posix. Especially, there is no advantage of array[n]
> regarding the stack overflow issue.
    See above.
>
> Of course, critical software should not rely on dynamic stack allocation
> since its unpredictable. (but also not on runtime heap allocation too)
    malloc() returns NULL il case of error. Errors should always be checked.


--     Didier