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

Martin Sebor msebor@gmail.com
Thu Mar 30 22:00:00 GMT 2017

On 03/30/2017 02:24 PM, Jakub Jelinek wrote:
> On Thu, Mar 30, 2017 at 10:21:09AM -0600, Martin Sebor wrote:
>> 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
> The Asan ICE can be easily worked around, the reason I don't want to do that
> is that this is the second time this broke something; the FE should
> not pass a VLA static constant (STRING_CST in this case) to the middle-end,
> VLA objects can be by definition only automatic variables or something
> on the heap, never in the data/rodata sections.
> Plus, while for VLA initialized from arrays etc. we copy the initializer
> and zero initialize the rest, for VLA initialization by STRING_CST we
> just copy over the STRING_CST and the rest is uninitialized.

I agree that's a bug, one that should be fixed, but ion my view
it's not serious enough to justify disabling the feature altogether.

If every feature with a bug in it or that happens to trigger an ICE
with some combination of command line options had to be disabled
there wouldn't be much left.

As I said, a patch that fixes this exists.  I ran out of time to
resubmit it for GCC 7 but I plan to do it for GCC 8.  It be quite
unfriendly to users to have GCC 7 reject working code that's
accepted by GCC 6 only to have GCC 8 accept it again.

I know you have concerns about the runtime costs of the patch
and I'm willing to listen and work with you to minimize the
performance impact.


More information about the Gcc-patches mailing list