Le 22/07/2021 à 20:53, Andreas Messer a écrit :
> Hi,
>
> On Thu, Jul 22, 2021 at 07:53:58AM +0200, Didier Kryn wrote:
>>     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.
> I don't find any reference about automatic variables in the docs regarding
> this topic.
    AFAIK, in the C language, stack == automatic variables.
> Actually, the description of gcc's alloca() builtin states that
> it behaves similar to automatic variables.

    This only means that it takes space from the stack. I've read also
that using it together with automatic variables of dynamic size, or,
even, embedded control blocks, is UB. Which means the compiler and
runtime are not properly informed. That said, it is possible that
compiler authors have made progress on this matter without updating the
documentation.

> However, all these macros will
> not prevent you from stack overflow but only help you to detect one when it
> already happened. Also, the way gcc implements the check (probing SP) works
> for alloca and for automatic variables in the same way.
>
> However, once you have detected a stack overflow, your application is
> in an inconsistent state. Of course you can implement some kind of rescue.
> (e.g using libsigsev) But you have to do a clean rewind of your app
> state back to state before the overflow occurred. This can become quite
> complex and hard to maintain. And then your're back to state before stack
> overflow, but what is the application supposed to do then? Log and ignore
> the request? Terminate? Ask the User?
>
> The point is, an application should be designed such that a stack overflow
> just can not occur. And this implies length checking, regardless if using
> automatic vars or alloca.
    There is always something safer than UB: crash.
>
>>     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().
> No. This is wrong alloca() is implemented as compiler builtin and
> does exactly the same as GCC does when allocating automatic vars on the
> stack.
>
> Prove: https://godbolt.org/z/abqK4T43c

> The generated machine code is identical including the stack overflow
> checking code.

    Generated code is normally not a proof. In the job of a compiler,
generating code is not necessarily the biggest part. Compile-time
controls and the generation of runtime checking code, when necessary,
are also essential. Here you tell the runtime verifications are the same
and I believe you - I don't know arm assembler; I used to read/write
assembler for PDP15 and IBM370 but it was  30-40 years ago (~:

    However the manual of alloca() states that "There is no error
indication if the stack  frame  cannot  be  extended." If the same would
happen with automatic variables, I would expect a crash; otherwise it
would be a serious flaw in the compiler. According to you there is such
a flaw?

    Cheers.

--     Didier