Re: [PATCH] tweak -Wplacement-new to fix #69662

[Martin Sebor <msebor at gmail dot com>]

On 02/04/2016 02:10 PM, Jason Merrill wrote:
> On 02/04/2016 03:22 PM, Martin Sebor wrote:
> > +  /* Refers to the declared object that constains the subobject
> > referenced
> > +     by OPER.  When the object is initialized, makes it possible to
> > determine
> > +     the actual size of a flexible array member used as the buffer
> > passed
> > +     as OPER to placement new.  */
> > +  tree var_decl = NULL_TREE;
>
> This doesn't make sense to me.  There should never be variables of types
> with flexible array members; such types should be allocated with malloc
> or the equivalent, along with enough extra space for the trailing array.
>   Indeed, the C compiler gives an error for initialization of a flexible
> array member.

Gcc (in C mode) accepts, as an extension, statically initialized
objects of structs with flexible array members.  It rejects them
in other contexts (such as auto variables).

G++ accepts initialized objects of structs with flexible array
members in all contexts.  I don't know for sure if this difference
is intended or accidental but since C++ allows more safe constructs
than C does, and I can't think of anything wrong with allowing it,
the patch handles this case.  If we decide that initializing such
structs is a bad idea in C++ the special handling can be removed.

FWIW, I've been opening bugs for problems in this area as I find
them hoping to not just document them but also get a more complete
understanding of what's allowed as an extension and what's likely
a bug (and why), and eventually submit fixes.

For example, 68489 points out a problem with allowing arrays of
flexible array members.  Since there's no good way to fix that
problem such arrays should be rejected.  But I haven't been able
to come up with a reason why individual automatic structs with
flexible array members should be disallowed.  If there is such
a reason, we can start diagnosing them.  But I would be reluctant
to start outright rejecting them if they're potentially useful
because it could break working programs.

Martin