instead of being namby pamby with the stack, it's simply better to take all of the desired maximimum. in zig, there's even provided a way to wrap it in an allocator so you can pretend like it's on the heap!

▲

do_not_redeem 3 days ago | parent | next [-]

This conversation would benefit from using more rigorous technical terminology than "namby pampy". There is nothing namby pamby about allocating the precise amount of space that you need, and keeping your app's memory footprint optimized. That's called engineering.

▲

throwawaymaths 3 days ago | parent [-]

real question: what are you going to do with the rest of the stack? are you in a situation where the stack and the heap might collide because you're that tight on resources? and let's say you take a function call that is about to overflow the stack. what should happen? error? panic? return null? silent fail?

there are no good choices in the case where you really need that thing you claim to need. recognizing that fact and picking different strategy is good engineering.

	▲	uecker 3 days ago \| parent \| next [-]
		The first stack / heap collisions were not using VLA but fixed size arrays on the stack. Nowadays compilers do stack probing, which solves this problem also for VLAs. Yes, you get a segfault for stack overflow, but this has not much to do with VLAs or not, but with putting too much stuff on the stack. The thing is, VLAs allow you to reduce stack usage, by putting the right amount of stack on the stack and not a worst case. The only downside is that they make it harder to control stack usage, but not a lot harder. So no, I do not think avoiding VLAs is good engineering.
	▲	do_not_redeem 3 days ago \| parent \| prev [-]
		This whole post is a strawman. I never said my reason was being tight on resources. Please reread the thread. Also don't forget that on modern architectures, the stack and heap can't "collide", because of guard pages. > what are you going to do with the rest of the stack? I'll leave it for the rest of the system. My app will use less memory, and since memory locality is improved, there will be fewer cache misses, meaning it runs faster too. > let's say you take a function call that is about to overflow the stack Stack overflows are impossible thanks to the comptime upper_bound parameter. That's the entire premise of this thread.

▲

CJefferson 3 days ago | parent | prev [-]

Yes, let's be "namby Pamby" with the cache lines storing the hot part of the stack, that sounds like an awesome idea!

I thought Zig was all about maximum performance. Sometimes I just want a little bit of stack memory, which will often already be in L1 cache.

	▲	achierius 2 days ago \| parent [-]
		Zig does allow this, that's what GP is saying. You don't actually need to relocate your stack, you can just declare a portion of your stack (i.e. what would otherwise be the next N frames) to be the stack you'll use for recursion, and thereafter use that to recurse in to.