From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 465BB3858D39; Mon, 23 Oct 2023 11:58:44 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 465BB3858D39
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1698062324;
	bh=4ubl2ke3Atj3NyHpVBMEOn2qAqReqPocsinV/6/0Jdo=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=qK+MAgDYyuGPH/oo6c68DFz/I1GOs6O6riSLkT6W/fdm7ixg29yNKNd0spOh4j5GT
	 ihD5KSDuS8ECld4BfVtaxeqKw1LXGIlvXp1eJzHRO056EQBrArc4aUu6p7KPFqSOyb
	 G9XnOWNO85DswgP2IaGBJyMloQMLSqqikF3TkDKA=
From: "muecker at gwdg dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/110848] Consider enabling -Wvla by default in non-GNU C++
 modes
Date: Mon, 23 Oct 2023 11:58:42 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: muecker at gwdg dot de
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-110848-4-5hFdjKqNnm@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110848-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110848-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D110848

--- Comment #25 from Martin Uecker <muecker at gwdg dot de> ---

I agree that they are not idiomatic C++ and that there exist good reasons w=
hy a
programmer may want to  avoid them (including standards compliance). But co=
de
not being idiomatic is not a terrible good reason for having a warning. As a
matter of principle, we should not warn about our own extensions without a =
very
good reason with -std=3Dgnu modes and neither should clang IMHO.

But the idea that VLAs are inherently very dangerous is incorrect, so let's=
 not
perpetuate that myth.  There are many useful things a compiler could do to
improve security for VLAs and also for std::vector or elsewhere by having
better static analysis and more efficient options for bounds checking.  Nei=
ther
clang nor GCC will currently give any compile-time warning about a problem =
here
with -Wall -Wextra nor will there be a run-error with UBSan:

https://godbolt.org/z/7vhGMn3E5

And yes, -D_GLIBXX_DEBUG which will detect the out-of-bounds access but not=
 the
memset. Maybe -D_FORTIFY_SOURCE=3D3 will do this (as it does for VLAs), but=
 it
does not seem to work on godbolt for both cases, so I can't check.  Asan wi=
ll
catch both.

For comparison, with VLAs we have this:

https://godbolt.org/z/hGxGrc569=