This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] 69517 - [5/6 regression] SEGV on a VLA with excess initializer elements


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]