On Sat, Jul 24, 2021 at 05:35:10PM +0200, Didier Kryn wrote:
>     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?

I have just made a short experiment. On linux, typical stack size is
8MB ( ulimit -s). So using the following test program:

stack_overflow.c:


#include <stdlib.h>
#include <stdio.h>

void
test(int size, int use_it)
{
#if 1
volatile int var[size/sizeof(int)];
#else
volatile int* var = alloca(size);
#endif

  if(use_it)
    var[0] = 0;
}

int
main(int argc, char* argv[])
{
long size = argc > 1 ? atoi(argv[1]) : 1024;
long use_it = argc > 2 ? atoi(argv[2]) : 0;

printf("Will be allocating %ldkb stackframe %s access\n", size, use_it ? "with" : "without" );

test(size*1024, use_it);
}


I get the following results:

...:/tmp$ gcc -o stack_overflow stack_overflow.c
...:/tmp$ ./stack_overflow 16000 0
Will be allocating 16000kb stackframe without access
...:/tmp$ ./stack_overflow 16000 1
Will be allocating 16000kb stackframe with access
Speicherzugriffsfehler
...:/tmp$ gcc -o stack_overflow stack_overflow.c -fstack-check
...:/tmp$ ./stack_overflow 16000 0
Will be allocating 16000kb stackframe without access
Speicherzugriffsfehler
...:/tmp$ ./stack_overflow 8000 0
Will be allocating 8000kb stackframe without access


So if -fstack-overflow is not used, the program will crash only if
memory is actually accessed out of bounds of the stack memory. Indeed,
accessing the last instead of the first array element does not crash
at all.

With -fstack-overflow it will already crash on allocation of the array.
(as expected)

When using the alloca() way, I get identical results.

Why I'm so critical about letting it crash: I typically deal with stack
sizes of no more around 2-8kB in automation devices and have to be careful
with that. You can't simply let a newspaper printing machine's motor control
crash, 1000's of newspaper pages would be trashed. Once we had a crash in
simple limit switch device. As a result the high-rack robot pushed a
pallet in 15m height out of the rack. Fortunately, it was just another
robot which was destroyed (stood just below) - not a human being. Still
a very expensive case for the company. So I'm used implement a lot of
checks :-). (Actually we even don't use heap allocation after booting
the firmware)

cheers,
Andreas

--
gnuPG keyid: 8C2BAF51
fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51