[PATCH] diagnosing flexible array assignments

Aaron Ballman aaron at aaronballman.com
Thu Sep 12 12:58:13 PDT 2013

So declarations are a bit more hairy.  It seems that GCC allows static
initalization of flexible array members as an extension:
Also, the C standard itself shows a declaration of a value type using
a flexible array member (granted, it is to show what could be
undefined behavior): (ISO/IEC 9899:2011):

struct s { int n; double d[]; };
struct s t1 = { 0 }; // valid
struct s t2 = { 1, { 4.2 }}; // invalid
t1.n = 4; // valid
t1.d[0] = 4.2; // might be undefined behavior

With that in mind, are declarations still worth diagnosing on, or are
expressions sufficient?  Note, the expression-based approach does
cover Athur's example of function calls.


On Tue, Sep 10, 2013 at 7:36 PM, Arthur O'Dwyer
<arthur.j.odwyer at gmail.com> wrote:
> On Tue, Sep 10, 2013 at 3:12 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>> On Tue, Sep 10, 2013 at 2:50 PM, Aaron Ballman <aaron at aaronballman.com> wrote:
>>> >>
>>> >> Hmmm, would there ever be a case where it would make sense to declare
>>> >> a structure with a flexible array member as a value type? The only
>>> >> situation I could think of would be overlaying the value type with
>>> >> stack-allocated memory in some sort of bizarre union type punning
>>> >> scenario.  So I'm thinking that may be a better approach than checking
>>> >> on assignment, unless there are intermediary ways you could get this
>>> >> assignment to happen in C.
> [...]
>>>   Assignment would be the catch-all way to do it, since that's
>>> what causes the slicing behavior.  Perhaps both declaration and
>>> assignment diagnostics would make sense?  Declarations like that are
>>> definitively bizarre, but assignment still misbehaves.
> Remember to consider
>     void foo(struct S s) { ... }    ... foo(s); ...
> which doesn't contain any assignment-expressions, but still slices the
> struct (if I understand correctly). So yeah, you'll want to have
> warnings on declarations *and* assignments.
> –Arthur

More information about the cfe-commits mailing list