This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] 69517 - [5/6 regression] SEGV on a VLA with excess initializer elements
- From: Martin Sebor <msebor at gmail dot com>
- To: Jason Merrill <jason at redhat dot com>, Gcc Patch List <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 23 Mar 2016 13:47:36 -0600
- Subject: Re: [PATCH] 69517 - [5/6 regression] SEGV on a VLA with excess initializer elements
- Authentication-results: sourceware.org; auth=none
- References: <56DCDB80 dot 90208 at gmail dot com> <56F2DD43 dot 2000206 at redhat dot com>
Thanks for the comments.
2) It hardwires a rather arbitrarily restrictive limit of 64 KB
on the size of the biggest C++ VLA. (This could stand to be
improved and made more intelligent, and perhaps integrated
with stack checking via -fstack-limit, after the GCC 6
release.)
The bounds checking should share code with build_new_1.
I agree that sharing the same code is right long term approach.
I had initially started out down that path, by factoring out code
from build_new_1 into a general function that I had thought could
be shared between it and cp_finish_decl. But I ended up abandoning
that approach two reasons:
a) The checking expression built for array new is quite a bit less
involved because only the major dimension of the array in requires
runtime checking (the others must be constant and are checked at
compile time). In contrast, all VLA dimensions are potentially
dynamic and so must be checked at runtime.
b) While (a) can be solved by making the checking function smart
and general enough, it felt too intrusive and potentially risky
to change array new at this stage.
That said, I'm happy to do this refactoring in stage 1.
3) By throwing an exception for erroneous VLAs the patch largely
defeats the VLA Sanitizer. The sanitizer is still useful in
C++ 98 mode where the N3639 VLA runtime checking is disabled,
and when exceptions are disabled via -fno-exceptions.
Disabling the VLA checking in C++ 98 mode doesn't seem like
a useful feature, but I didn't feel like reverting what was
a deliberate decision.
What deliberate decision? The old code checked for C++14 mode because
the feature was part of the C++14 working paper. What's the rationale
for C++11 as the cutoff?
Sorry, I had misremembered the original C++ 14 check as one for
C++ 11. Are you suggesting to restore the checking only for C++
14 mode, or for all modes? Either is easy enough to do though,
IMO, it should be safe in all modes and I would expect it to be
preferable to undefined behavior.
Martin