3 ms·

Maybe you did not realize this, but I somewhat helped with this effort. In the kernel it may make (some) sense. The overall idea that VLA are always bad is inco

by uecker 4y ago

Maybe you did not realize this, but I somewhat helped with this effort. In the kernel it may make (some) sense. The overall idea that VLA are always bad is incorrect.

pjmlp 4y ago
It is hard to link an empty profile to anything. The people at WG14, Google and Microsoft (VLAs are one of few C99 features not ever coming to MSVC) think otherwise. So you're basically saying they are wrong.
- Gibbon1 4y ago
  Your appeal to authority using WG14 (hapless goldbricks) and google/Microsoft (C++ shops) falls really flat.
  - pjmlp 4y ago
    That authority drives the C language evolution and couldn't care less about what you, or me for that matter, think.
    - uecker 4y ago
      And I am part of WG14 (so a hapless goldbrick). The reason VLA were made optional to make implementing C easier, as C99 was not adopted quickly. Although the reason for the slow adoption were others. MSVC did not really support C at all at C99 time because they thought everyone should transition to C++. Only very recently C support catched up in MSVC.
      - pjmlp 4y ago
        Great, so when is the C11 rationale getting published? https://groups.google.com/g/comp.std.c/c/E0yxHfpcOfY https://groups.google.com/g/comp.std.c/c/E0yxHfpcOfY
        Jorengarenar 4y ago
        IIRC, there will be no more rationales
    - Gibbon1 4y ago
      Obviously since they've done literally nothing in the last 20 years.
Jorengarenar 4y ago
> The overall idea that VLA are always bad is incorrect. I mean, I'm yet to see a definitive example where automatic* VLA was actually right tool for the job. I know they were supposedly introduced for the numerical analysis, but I fail to see what problem it actually did solve. Yes, the syntax way neater than piecemeal allocation, but it could have been solved with functions and macros anyway. Did VLA just hit some sweet spot in performance between fixed size arrays and heap-allocated ones, which made number crunching better optimized? * as opposed to VM types used in function parameters and for allocating multi-dimensional arrays on heap
- uecker 4y ago
  Stack allocation is much faster than heap allocation, and compared to fixed-size arrays VLAs save stack space. For example, a recursive divide-by-conquer algorithm that allocates arrays on the stack may use log(n) stack space compared to n². Using VLAs instead of the heap simplifies the logic because you get automatic deallocation with proper scoping. VLAs and VM were introduced as one feature, so I am not sure there was ever a the question of adding only one of them. In terms of security, there are some issues but it is largely overblown and misunderstood. A dynamic buffer is always a sensitive piece of code when dealing with data from the network. VLA were the language tool of choice and then got a bad reputation because they were involved in many CVEs. But correlation is not causation. The main real issue is that - if the attacker can control the size of the VLA -, it is possible to overflow the stack into the heap. This can be avoided by using stack clash protection which compilers support only since a couple of years. With stack protection I believe VLAs can be safer than fixed size arrays due to improved bounds checking.
  - Jorengarenar 4y ago
    > The main real issue is that - if the attacker can control the size of the VLA -, it is possible to overflow the stack into the heap. I think the main gripe most programmers have with VLA is lack of control over them. Fixed size array is, nomen omen, fixed and predictable - can even be tested beforehand. malloc() at least returns NULL on fail (although memory overcommitment muddies the situation), so program can take some action. But what happens when VLA fails? Segfault? Stack crash protection if compiled with it or worse if without? None of those options is graceful from the perspective of end user. > This can be avoided by using stack clash protection which compilers support only since a couple of years. As you yourself say, it's been only few years since this protection made its way into compilers. But that's not the issue. The issue is that `-fstack-clash-protection` isn't part of C language, it's part of compiler. What's the incentive for the developer to use less certain feature when there are easier alternatives?

by uecker 4y ago

Maybe you did not realize this, but I somewhat helped with this effort. In the kernel it may make (some) sense. The overall idea that VLA are always bad is incorrect.

pjmlp 4y ago

It is hard to link an empty profile to anything. The people at WG14, Google and Microsoft (VLAs are one of few C99 features not ever coming to MSVC) think otherwise. So you're basically saying they are wrong.

Gibbon1 4y ago
Your appeal to authority using WG14 (hapless goldbricks) and google/Microsoft (C++ shops) falls really flat.
- pjmlp 4y ago
  That authority drives the C language evolution and couldn't care less about what you, or me for that matter, think.
  - uecker 4y ago
    And I am part of WG14 (so a hapless goldbrick). The reason VLA were made optional to make implementing C easier, as C99 was not adopted quickly. Although the reason for the slow adoption were others. MSVC did not really support C at all at C99 time because they thought everyone should transition to C++. Only very recently C support catched up in MSVC.
    - pjmlp 4y ago
      Great, so when is the C11 rationale getting published? https://groups.google.com/g/comp.std.c/c/E0yxHfpcOfY https://groups.google.com/g/comp.std.c/c/E0yxHfpcOfY
      - Jorengarenar 4y ago
        IIRC, there will be no more rationales
  - Gibbon1 4y ago
    Obviously since they've done literally nothing in the last 20 years.

Jorengarenar 4y ago

> The overall idea that VLA are always bad is incorrect. I mean, I'm yet to see a definitive example where automatic* VLA was actually right tool for the job. I know they were supposedly introduced for the numerical analysis, but I fail to see what problem it actually did solve. Yes, the syntax way neater than piecemeal allocation, but it could have been solved with functions and macros anyway. Did VLA just hit some sweet spot in performance between fixed size arrays and heap-allocated ones, which made number crunching better optimized? * as opposed to VM types used in function parameters and for allocating multi-dimensional arrays on heap

uecker 4y ago
Stack allocation is much faster than heap allocation, and compared to fixed-size arrays VLAs save stack space. For example, a recursive divide-by-conquer algorithm that allocates arrays on the stack may use log(n) stack space compared to n². Using VLAs instead of the heap simplifies the logic because you get automatic deallocation with proper scoping. VLAs and VM were introduced as one feature, so I am not sure there was ever a the question of adding only one of them. In terms of security, there are some issues but it is largely overblown and misunderstood. A dynamic buffer is always a sensitive piece of code when dealing with data from the network. VLA were the language tool of choice and then got a bad reputation because they were involved in many CVEs. But correlation is not causation. The main real issue is that - if the attacker can control the size of the VLA -, it is possible to overflow the stack into the heap. This can be avoided by using stack clash protection which compilers support only since a couple of years. With stack protection I believe VLAs can be safer than fixed size arrays due to improved bounds checking.
- Jorengarenar 4y ago
  > The main real issue is that - if the attacker can control the size of the VLA -, it is possible to overflow the stack into the heap. I think the main gripe most programmers have with VLA is lack of control over them. Fixed size array is, nomen omen, fixed and predictable - can even be tested beforehand. malloc() at least returns NULL on fail (although memory overcommitment muddies the situation), so program can take some action. But what happens when VLA fails? Segfault? Stack crash protection if compiled with it or worse if without? None of those options is graceful from the perspective of end user. > This can be avoided by using stack clash protection which compilers support only since a couple of years. As you yourself say, it's been only few years since this protection made its way into compilers. But that's not the issue. The issue is that `-fstack-clash-protection` isn't part of C language, it's part of compiler. What's the incentive for the developer to use less certain feature when there are easier alternatives?