4 ms·

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

by uecker 3y ago

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 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.)

pjmlp 3y ago
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?
- uecker 3y ago
  I do not know for sure, but there are now more people in WG14 which care about safety, so I would say yes.
  - pjmlp 3y ago
    I hope enough to win when security goes to votes.
addaon 3y ago
> 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?
- uecker 3y ago
  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.
  - addaon 3y ago
    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.

by uecker 3y ago

pjmlp 3y ago

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?

uecker 3y ago
I do not know for sure, but there are now more people in WG14 which care about safety, so I would say yes.
- pjmlp 3y ago
  I hope enough to win when security goes to votes.

addaon 3y ago

> 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?

uecker 3y ago
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.
- addaon 3y ago
  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.