[tliltocatl]

Not mentioned: do not do any dynamic allocation at all. Never ever. Everything is either a global variable or goes on the stack. Doesn't work when you need to handle unknown input size, but when you need to make sure you don't OOM ever, it's the only way. Stack overflow is still a possibility, unfortunately, because existing languages cannot provide any guarantee here (Zig tried, but didn't got it done afair).

The only real problem with this approach is code reuse, because library writers will insist on opaque structs and malloc rather than letting the caller allocate.

[ryao]

What you describe is stack exhaustion. Stack overflow is running past the end of an object on the stack. “Memory safe” languages claim to protect against stack overflows, as does the astree sound static analyzer for C/C++:

https://www.absint.com/astree/index.htm

None make any mention of stack exhaustion that I can find in a cursory search.

[tliltocatl]

Wikipedia doesn't agree.

https://en.wikipedia.org/wiki/Stack_overflow

> In software, a stack overflow occurs if the call stack pointer exceeds the stack bound.

Also your searching astree site reveals:

> StackAnalyzer automatically determines the worst-case stack usage of the tasks in your appli­cation. It lets you find any stack overflows, or formally prove the absence thereof.

[ryao]

To me, stack overflow is a synonym for stack buffer overflow:

https://en.wikipedia.org/wiki/Stack_buffer_overflow

What you call stack overflow appears to be what I call stack exhaustion. The two different cases are very different things when you look at what happens in memory. In computers, the stack grows down, so exhausting the stack occurs in a downward direction. When you overflow an object on the stack, this typically occurs in an upward direction, and continues until older stack frames. Downward is also possible for that case, but it is rare and when it happens it can also be the other issue at the same time.

Hearing stack overflow used to describe the other kind of issue is what prompted my reply. I had not known that others use these terms differently. In all cases, we are describing something going past a boundary, with the only difference being what, so the ambiguous usage makes sense. The ambiguous usage appears to be acknowledged by Wikipedia:

https://en.wikipedia.org/wiki/Stack_overflow_(disambiguation...

I will continue to use stack exhaustion for this, as it is more accurate.

There is also a third case, which is jumping the stack guard page. I am not sure if you consider this to be a “stack overflow” too. It is a third class of bug. Wikipedia appears to lump it together with stack exhaustion under stack overflow.

I never expected bug taxonomy to be controversial, yet here we are.