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

[answer to m.mclean..i post it separately as for me that low level things are specially interesting and worth separate message imo..though
i kno sadly there are not much low lewel winapi likers people here, like me who likes low lewel and uses winapi]
this is not strictly true
well important knowledge which not mantyy programers know i think is that how the layout of program im memory of you system is exactly
and i think this knowledge should be learn "by heart" just to increase
understanding
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)..there is smal pe header loaded to ram then your assembly binary code (typical entry point it is first assemby instruction to run is at 0x00401000 ) then you got loaded const data (.data and .rdata)
after the machine code then you got, static empty arrays (.bss) (which are
usually big like 100 MB or more depending how many static arrays you got) (allso smaller sections also could be placed there .rsrc for example, .tls, .idata (imports), .CRT, .tls)
the dlls your program links to are placed from the top it is from 0x7fff ffff down below, both system ones, part side ones or yours own
system ones are optimised to not have .bss which consumes most of the memory so system dlls do not occupy lot of ram (hovevevr system dlls loads and i for example write pure winapi programs and still that system dlls loaded in my program space are nearly 20 od system dlls)
heap you got BETWEEN end of your code and begin of dlls, so if your program uses 300 MB od static tables (my fault as i used tod eclate a lot of static tables in various files) and your dlls in sum use 500 MB
(of their .bss mostly)  then your heap is limited to 1.3 GB on win32
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
(downside is it will not run on pc that have less that 100 MB ram as it couldnt alloocate stac i guess but some must assume some numbers today
probably, and sadly i would assume at least 2-4 GB and assuming less is optimisation)
(I also dont checked if there are some hardcoded limits for stack size like it cant be bigger than 1 Gb or so, could be checked)
some vaules some can obtain just by printfing pointers in c application, pointers to stack objectm, pointer to aray begoning pointer to some function, maybe pointer to dlls attached (its function or datya) and pointers to heap storage