Stack frames larger than 4K should be rejected, but what if I want more

[Walter Bright]

On 6/27/2021 2:08 PM, IGotD- wrote:
> On Sunday, 27 June 2021 at 19:41:40 UTC, Ola Fosheim Grøstad wrote:
>>
>> It makes no sense and would kill a system level language. The stack depth for 
>> Linux is 8MiB. 4KiB isn't even enough to fit a commonly sized FFT buffer, 
>> anything less than 16KiB is a joke IMHO.
> 
> Yes kind of, and I can think of use cases when you want big arrays on the stack. 
> The question is if the approach is correct. Walter wants to catch potential 
> memory corruption but limiting the stack usage (per function I assume) but in 
> this case the real solution would be reading the stack limit (probably with an 
> expensive system API but can be stored as a TLS variable).
> 
> On 64-bit systems there usually enough virtual space to put several megabytes of 
> guard regions. On 32-bit systems it is more cramped and perhaps only 4K. The 
> question is if this is something that should be dealt by the language.

There's a huge difference between the virtual address range set aside for the 
entire thread stack, and the amount of stack consumed by one function invocation.

Large amounts of stack allocated for one function's frame is almost always the 
result of an inexperienced system coder who doesn't realize what it means to 
allocate memory on the stack, how guard pages work, and how physical memory gets 
allocated as the stack grows.