[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.

Martin



More information about the Gcc-patches mailing list