Re: [C++ PATCH] Disable VLA initialization? (PR sanitizer/79993)

[Martin Sebor <msebor at gmail dot com>]

On 03/29/2017 01:31 PM, Jakub Jelinek wrote:
> Hi!
>
> GCC 4.8 and earlier didn't allow in C++ initialization of VLA and
> C doesn't allow it in any GCC release.  This has changed when the
> support for C++1y VLA has been added, then reverted, but apparently
> only partially.
>
> The question is, do we want to support VLA initialization, if yes,
> with what exact semantics (in that case we need to fix up initialization
> from STRING_CST which is broken right now).
>
> The following patch is the variant that disables it (bootstrapped/regtested
> on x86_64-linux and i686-linux).
>
> Looking at what is emitted for initialization from non-STRING_CSTs,
> it seems that we consider UB if the VLA is shorter than the initializer
> array, and if it is longer, we somehow initialize the rest (dunno what
> exact C++ initialization kind, there are some testcases
> with ctors in the list below; for PODs zero initialization).
>
> So, if we want to keep it and just fix STRING_CST initialization,
> shall we emit memcpy from the array followed by whatever we emit right now
> for the excess elements (for initialization from STRING_CST, can it ever
> be anything but zero initialization?  If not, then memset would do the job).

I already chimed in on the bug report but just for the record,
my view is that it would be preferable to continue to allow VLAs
to be initialized as long as the excess initialization isn't
allowed to trash the stack as it is now (bug 69517).  The patch
for that was committed into GCC 6 but had to be reverted due to
interfering with Java's own implementation of exception).  With
Java removed I'd like to resubmit the patch in GCC 8.

I don't think rejecting all VLA initialization just to avoid
an Asan ICE with string literals is a good way to solve the
problem.  For one, it will break working programs that rely on
what is currently accepted by GCC and for which it emits valid
code.  Longer term, users will likely come up with other ways
to initialize their VLAs that may be even harder (or slower)
for GCC to detect bugs in that the plain initialization.

Martin