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
