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
signature.asc
Description: PGP signature
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng