[PING][PATCH] make handling of zero-length arrays in C++ pretty printer more robust (PR 97201)

[Martin Sebor <msebor@gmail.com>]

Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554893.html

On 9/25/20 12:58 PM, Martin Sebor wrote:
> The C and C++ representations of zero-length arrays are different:
> C uses a null upper bound of the type's domain while C++ uses
> SIZE_MAX.  This makes the middle end logic more complicated (and
> prone to mistakes) because it has to be prepared for both.  A recent
> change to -Warray-bounds has the middle end create a zero-length
> array to print in a warning message.  I forgot about this gotcha
> and, as a result, when the warning triggers under these conditions
> in C++, it causes an ICE in the C++ pretty printer that in turn
> isn't prepared for the C form of the domain.
> 
> In my mind, the "right fix" is to make the representation the same
> between the front ends, but I'm certain that such a change would
> cause more problems before it solved them.  Another solution might
> be to provide APIs for creating (and querying) arrays and have them
> call language hooks in cases where the representation might differ.
> But that would likely be quite intrusive as well.  So with that in
> mind, for the time being, the attached patch just continues to deal
> with the difference by teaching the C++ pretty printer to also
> recognize the C form of the zero-length domain.
> 
> While testing the one line fix I noticed that -Warray-bounds (and
> therefore, I assume also all other warnings that detect out of bounds
> accesses to allocated objects) triggers only for the ordinary form of
> operator new and not for the nothrow overload, for instance.  That's
> because the ordinary form is recognized as a built-in which has
> the alloc_size attribute attached to it.  But because the other forms
> are neither built-in nor declared in <new> with the same attribute,
> the warning doesn't trigger.  So the patch also adds the attribute
> to the declarations of these overloads in <new>.  In addition, it
> adds attribute malloc to a couple of overloads of the operator that
> it's missing from.
> 
> Tested on x86_64-linux.
> 
> Martin