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

IGotD- nise at nise.com
Mon Jun 28 08:54:59 UTC 2021


On Monday, 28 June 2021 at 07:10:05 UTC, Ola Fosheim Grøstad 
wrote:
>
> D is trying to become a high level language, but is also aiming 
> to be system level and that is not really an attainable goal. 
> You have to make a choice. It would be better for D to not go 
> for 100% safe, but instead prevent common mistakes.
>
> I've never ran out of stack for any code I've written ever.
>
> Maybe that means allocating larger stacks so that guard pages 
> are never hit, add more guard pages and simply terminate when 
> guard pages are hit.
>

Hitting guard pages and you will get an exception and a core 
dump. That's one way to do it but there is no explicit message 
that you ran out of stack. By checking the stack limit for each 
frame you can gracefully exit and print a message. Any of these 
methods gives you a performance hit and I am a bit skeptical that 
it is worth it. I think it should be an opt in feature.

This kind of feature is similar to Visual Studio C/C++ debug mode 
which has extensive stack analysis for each frame. The 
performance hit very high for branchy code but I have discovered 
a lot of bugs the debug stack analysis. VS also put in guard 
patterns between stack variables so that you can detect if there 
is any overwrite within a frame. These kind of bugs are common in 
C/C++, mainly because there is no bounds checking with arrays.

I don't like limits on how I use the stack and if the programmer 
is an amateur is a weak argument. I really question how effective 
this limit is. I rather go the VS route which mean proper stack 
analysis in debug mode.



More information about the Digitalmars-d mailing list