https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
Xi Ruoyao changed:
What|Removed |Added
CC||qurong at ios dot ac.cn
--- Comment #26 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #25 from Martin Uecker ---
I agree that they are not idiomatic C++ and that there exist good reasons why a
programmer may want to avoid them (including standards compliance). But code
not being idiomatic is not a terrible good reas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #24 from Jonathan Wakely ---
(In reply to Martin Uecker from comment #22)
> There may be many good reasons to prefer std::vector over VLAs in C++ but
> security and safety is not one of them. There are plenty of CVEs caused by
> std:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #23 from Jonathan Wakely ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #22 from Martin Uecker ---
There may be many good reasons to prefer std::vector over VLAs in C++ but
security and safety is not one of them. There are plenty of CVEs caused by
std::vector out-of-bounds accesses. The question is whet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #21 from Jonathan Wakely ---
std::vector should be preferred in C++.
This warning will not drive responsible C++ developers to use alloca, it will
drive them to use std::vector. As Aaron has said, there are cases where people
use a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #20 from Martin Uecker ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #19 from Aaron Ballman ---
(In reply to Andrew Pinski from comment #18)
> (In reply to Aaron Ballman from comment #17)
> > In the time I opened this request, a new CVE related to VLAs came out:
> > https://bugzilla.redhat.com/show_b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #18 from Andrew Pinski ---
(In reply to Aaron Ballman from comment #17)
> In the time I opened this request, a new CVE related to VLAs came out:
> https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2023-4039
Everything is a security r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #17 from Aaron Ballman ---
(In reply to Martin Uecker from comment #16)
> I do not think -Wall should warn about GNU extensions when used with
> -std=gnu++XX in C++ and I think it is annoying that clang does it now. It
> only drives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #16 from Martin Uecker ---
I do not think -Wall should warn about GNU extensions when used with
-std=gnu++XX in C++ and I think it is annoying that clang does it now. It only
drives people to use alloca or other alternatives with wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #15 from Eric Gallager ---
(In reply to Eric Gallager from comment #14)
> Oh right, if we're considering changing things for plain-C here, too, then
> maybe have it enabled by -Wc++-compat there?
Or rather, for plain-C modes, where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #14 from Eric Gallager ---
Oh right, if we're considering changing things for plain-C here, too, then
maybe have it enabled by -Wc++-compat there?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #13 from Aaron Ballman ---
Just to circle back around on this topic, these are changes recently landed in
Clang:
https://github.com/llvm/llvm-project/commit/84a3aadf0f2483dde0acfc4e79f2a075a5f35bd1
It enables the -Wvla-extension dia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #12 from Aaron Ballman ---
(In reply to Eric Gallager from comment #11)
> How about:
>
> -std=c++XY: enabled by default (as per the proposal)
> -std=gnu++XY: enabled by -Wall and/or -Wextra (in addition to being enabled
> by -pedant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #10 from Aaron Ballman ---
(In reply to Jonathan Wakely from comment #9)
> Personally I'd like it diagnosed in GNU modes, but this is pretty much the
> poster child for "conforming extension diagnosed with -pedantic" so I can
> see t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #9 from Jonathan Wakely ---
Personally I'd like it diagnosed in GNU modes, but this is pretty much the
poster child for "conforming extension diagnosed with -pedantic" so I can see
the argument for not diagnosing it by default.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #8 from Aaron Ballman ---
(In reply to Richard Biener from comment #7)
> I think -std=c++XY should diagnose (at least with a warning) the use of GNU
> extensions. Let me alter the summary and confirm.
Thanks! I still think this sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
Richard Biener changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
Ever conf
20 matches
Mail list logo
