Item — HN Reader

Ah, thanks. I didn't know this proposal. I am trying to push similar things.

The main obstacle are people coming from MSVC or C++ not knowing variably modified types and people being convinced that VLAs are always bad. This then leads to many bad attempts at fixing the problem instead of simply using arrays which know their run-time length. While we still miss a bit of compiler support (I am working on it), this already helps today: https://godbolt.org/z/4a45xq5hr

(Update: Of course, the use of references in the proposal above and the motivation is a bit obscure. In any case, VM-types will not be optional in C23 anymore. And usage and interesting is going up.)

2 comments

Even Dennis tried back in the day, but WG14 wasn't interested in his proposal, and by then it wasn't his language any longer anyway.

So will WG14 finally care about C's safety?

I do not know for sure, but there are now more people in WG14 which care about safety, so I would say yes.

I hope enough to win when security goes to votes.

> and people being convinced that VLAs are always bad

(Stack allocated) VLAs are (almost) always bad. How do you prove absence of stack overflow in their presence?

Attacker controlled sizes are always bad, this is also true for heap allocations. With stack clash protection this becomes a DOS for VLAs (same as for heap allocations). But I am not saying that VLAs are always the right choice, but in many cases they are better than the next best alternative.

It's not about attacker control, it's about correctness of your code. Without VLAs then static analysis of the call graph (and absence of recursion) is sufficient to prove maximum stack depth; with VLAs then much deeper analysis is needed, if it's possible at all.