This is a breakout thread from this thread.

https://forum.dlang.org/thread/ghodronzxeirokyoqeag@forum.dlang.org

According to the comment from Walter.

As per Walter's recent comment in that thread, he asserts that stack allocations beyond 4k should be rejected.

in this issue:
https://issues.dlang.org/show_bug.cgi?id=17566

In general I can agree with the rationale to not allow stack frames larger than 4K when it comes to normal programming, it makes sense. However, since D is supposed to be a "systems programming language" the language should not dictate what the programmer should be able to do with the stack. It also assumes things that all systems have 4K page sizes, that the stack should be used moderately. There might be cases when the programmer wants to go nuts with stack and do a lot storage on it, for whatever reason. Therefore I think this limit should not be a language definition.

First this 4K limit should be configurable per operating system. Also there should be an option to override this limit, for example with a compiler option.

On Sunday, 27 June 2021 at 18:56:57 UTC, IGotD- 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.

On Sunday, 27 June 2021 at 18:56:57 UTC, IGotD- 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.

On Sunday, 27 June 2021 at 19:41:40 UTC, Ola Fosheim Grøstad wrote:

While it's not specified in "The compiler should reject any stack frame that's larger than 4K", I think it's only meant to apply to @safe functions, not @system or @trusted ones.

Also, instead of straight up rejecting large stack frames in @safe code, the compiler could also start such a function with probing the guard page by making writes at intervals of 4K.

On Sunday, 27 June 2021 at 19:41:40 UTC, Ola Fosheim Grøstad wrote:

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.

On Sunday, 27 June 2021 at 20:17:48 UTC, Dennis wrote:

Actually, that's hard to realize, since the check for @safe is a semantic check in the frontend, while final stack sizes are only known by the backend. Making the frontend guess an upper bound is hard because of tail calls and/or inlining, e.g:

void f(ubyte[] x) {
    ubyte[4000] bufA = void;
    g(bufA[]);
}

void g(ubyte[] bufA) {
    ubyte[4000] bufB = void;
    h(bufA, bufB);
}

void h(ubyte[] x, ubyte[] y);

With ldc -O3, the stack frame of f is 8008 bytes because it has g inlined.

On Sunday, 27 June 2021 at 22:01:22 UTC, Dennis wrote:

void f(ubyte[] x) {
    ubyte[4000] bufA = void;
    g(bufA[]);
}

void g(ubyte[] bufA) {
    ubyte[4000] bufB = void;
    h(bufA, bufB);
}

void h(ubyte[] x, ubyte[] y);

That's a good observation. Does this mean that the point of the suggested 4K limit falls?

In practice, if you want to prevent stack overflow and be sure about it I think you need a check for every new frame. This has a performance impact but safety usually has a that.