On Monday, 28 June 2021 at 11:39:27 UTC, SealabJaster wrote:

printf and conversion functions are usually a typical example of functions that use large buffers on the stack. There is usually no problem with this as rich OSes have plenty of virtual stack space. If this wasn't allowed you would need to dynamically allocate memory of every printf call if not several depending what you print. This would slow down the printing function and another problem for embedded systems/systems programming is that you might want to print something before malloc/free are initialized.

Big buffers on the stack is not always because the programmer is an amateur.

On 6/27/21 2:56 PM, IGotD- wrote:

Could this be fixed by not allowing uninitialized stack segments larger than 4k? Basically, if you can't create a stack which contains a contiguous 4k of uninitialized space, then you can't skip over the guard page.

void-initialized data is pretty rare in D.

-Steve

On Monday, 28 June 2021 at 12:41:20 UTC, Steven Schveighoffer wrote:

Why? When you decide not to initialize you also surpass the safety benefits of initialized values.

On 6/28/21 9:09 AM, IGotD- wrote:

The point is to ensure the guard page is triggered. This is not about the safety of initialized values. It's about making sure the stack pointer stays sane. I don't know about you, but I don't want to start having to worry about stack pointer correctness, even in system code.

This would be like saying null pointer dereferences only trigger a segfault in safe code, so now all system code that doesn't want to corrupt some mmapped data at the null page must first check that a pointer is not null before using. It's nonsense.

-Steve

On Monday, 28 June 2021 at 14:01:50 UTC, Steven Schveighoffer wrote:

If you want stack overflow safety for whatever reason, then you should do proper bounds checking for each frame. I consider the 4K limitation and poking stack pages ahead to be just hacks.

On Monday, 28 June 2021 at 14:01:50 UTC, Steven Schveighoffer wrote:

Trapping page 0 is not foolproof. For instance if you have a pointer to a static array, you could easily be outside the range that will trap. Not all hardware can trap page 0 either. So you do end up with a solution that works often, but not always. But for stacks specifically, there is nothing that prevents you from having multiple guard pages.

Just make it user configurable: min stack depth, max stack depth, number of guard pages.

On Monday, 28 June 2021 at 14:40:12 UTC, IGotD- wrote:

Ditto. D shouldn't become a vendor.

On Sunday, 27 June 2021 at 18:56:57 UTC, IGotD- wrote:

I recall that Pascal debug builds added manual checks for stack overflow. This was especially necessary in real mode, where a stack overflow would just crash the PC. I don't see why D couldn't do the same. It would be useful in protected mode with small variables too, as it would allow generating a normal D exception instead of a segmentation fault.