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

bart wrote:

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.
>

but you call this function badly designed becouse it can overflow stack
- if it cant it is not badly designed then (unles you say on something other)
this recursion in fact is not badly designed imo - you only need to be aware of constraints of data you used it to (and if you care of constraints of your code you could also somewhat care of constraints on data)
its suboptimal as to speed but i wouldnt cal it "badly designed"
as i said in another thread the error may be to declare stack size,
it not necessarely need to be declared maybe - then you use stack until the ram will end - as today people use normal ram, nearly none application is ready to situatuion that ram ends and heap alocations fail..so with stack may be tha same

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.
>
>

there was an shortcut in it you dont need to pass the 2 colors in calls so i think it rather should use int x int y and ret adress it is 12 bytes (on 32 bit, i compile 32 bit only)