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.