https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #23 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Martin Uecker from comment #20)
> And what alternative do you think is fundamentally safer than VLAs?
>
> VLAs know their bound. Thus, they integrate with _FORTIFY_SOURCE, and UBSan
> bounds checking. Also UBSan address checking at run-time. At compile-time
> there is -Ws
They don't integrate with idiomatic C++ such as ranges algorithms, and
std::end.
More generally, they simply don't integrate with the C++ type system, so are
unusable with most generic code using templates. Not only does std::is_array
not recognise them as arrays, but even attempting to ask the question with
std::is_array is ill-formed. Variably modified types are not part of the C++
type system, so can't be template arguments.
int n = 2;
int a[n]{};
static_assert(not std::is_array_v<decltype(a)>); // error
Clang doesn't even allow the {} initializer in the code above, so they're not
portable either, even among compilers that support -std=gnu++17 modes.
> std::vector<int> has some protection, e.g. ASAN finds the out of bounds
> access (at a high run-time cost) and one could activate the GLIBC assertions
> someho:
>
> https://godbolt.org/z/8zanMG5x4
This will abort with the recommended hardening flags, specifically
-D_GLIBCXX_ASSERTIONS (which is nothing to do with Glibc, and is suitable for
production use, unlike ASan). Those assertions will be enabled by the proposed
-fhardening flag.
>
> But I would not call it safer and overhead is much worse.
>
> Fundamentally, VLAs are the dynamic buffer which can be protected most
> easily and should be *preferred*.
Maybe for C, but not for C++.
I know you are a big fan of VLAs, but please don't try to push them into a
language where they do not fit, and are not needed.
