[CC Jason]

The patch is at the link below:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01803.html

Thanks

On 10/19/2015 12:50 PM, Martin Sebor wrote:
This is a patch for two C++ bugs:

   67913 - new expression with negative size not diagnosed
   67927 - array new expression with excessive number of elements
           not diagnosed

The C++ front end rejects a subset of array declarators with negative
bounds or with bounds in excess of some implementation defined maximum
(roughly SIZE_MAX / 2), but it does so inconsistently.  For example,
it silently accepts expressions such as

     new int [-1][2];

but invokes operator new to allocate SIZE_MAX bytes.  When operator
new succeeds (as is the case on Linux with memory overcommitment
enabled), the new expression returns a valid pointer to some
unknown amount of storage less than SIZE_MAX.  Accessing the memory
at some non-zero offset then causes a SIGSEGV.

Similarly, GCC accepts the following expression with the same result:

     new int [SIZE_MAX][2];

C++ 14 makes it clear that such expressions are ill-formed and must
be rejected.  This patch adds checks that consistently reject all
new expressions with both negative array bounds and bounds in excess
of the maximum.

While I raised these bugs as separate issues I decided to group the
two sets of changes together since they both touch the same function
in similar ways, and hopefully doing so will make them also easier
to review.

I've tested the patch by bootstrapping C/C++ and running the test
suites (including libstdc++) on x86_64 with no regressions.

During the development of the changes I found a few basic mistakes
in my code only after running libstdc++ tests.  To make it possible
to uncover them sooner in the future, I added another test that
isn't directly related to the problem: new45.C.

I also found a minor problem in the GCC regression test suite where
the g++.dg/other/new-size-type.C test for PR 36741 tried to check
that the 'new char[~static_cast<size_t>(0)]' expression was accepted
without a warning.  The complaint in the PR was about the wording of
the warning, not about the validity of the expression (the submitter
agreed that a correctly worded diagnostic would be appropriate).
  I chaged the test to expect a meaningful error message.

Once this patch is approved and committed a follow-up patch should
document the implementation-defined maximum to the manual.

Martin

Reply via email to