Re: > fails. Because heaps are unlimited whilst stacks are not.

On 20/03/2024 14:02, fir wrote:

i know somewhat how it looks like in win32 :
 generally the addres space aplication have os from 0x0000 0000 to 0x7fff ffff - which is only 2 gigabytes
 (hovever i like it and still prefer writing my windows programs on win32 than win 64, 2 gigabytes of ram is enough for me)
 your program is by default placed at 0x0040 0000 (which is 4MB from start of adres space)..

That's no longer the case with 64-bit machines, not if you use products like gcc. This program:
   #include "stdio.h"
   int main(void) {
       printf("%p\n", main);
   }
displays 00007ff64a931591 when compiled with gcc. Even on 32-bits using `gcc -m32`, it shows 0076155c.

 at least this is what i know
  the stack in turn is betwwwen your app start that +4MB and the starting point, im not exactly syre but its probably something about +3M down do +1M approximatelly
 stack could be set to bigger in your exe heder your exe has 9may be modified by -something switch in gcc comandline) and i not tested it afair (or rather tested but forgot the strict conclusions) but i dont
se nthing specially wrong even in setting this stack to 100 MB
 2 MB by default is silly and if you have 10 GB of ram putting 100 MB for stack is not even a waste becouse if it is not used it only consumes "logical" ram pages afair but reall ram is not even attached

I don't think using a giant stack just one for the benefit of one badly-designed function in one library inside a big application is a good approach.
Maybe the routine is never called. Or it's called once then never called again but the stack is now committed.
Your floodfill routine uses 48 bytes per call (with my compiler; it varies). To floodfill all the pixels in a 3000x4000 pixel image for example, would need nearly 600MB of stack, and would involve calls nested 12 million deep.