[cfe-dev] Flexible array members in ObjC classes

[David Chisnall via cfe-dev]

> On 21 Sep 2017, at 11:04, Nat! via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> David Chisnall schrieb:
>> On 21 Sep 2017, at 10:07, Nat! via cfe-dev<cfe-dev at lists.llvm.org>  wrote:
>>> My second reaction, was to think that there are class cluster classes with allocate a flexible amount of memory (say string classes) that aren't ususally subclassed. Who am I to say, that using a convenient flexible array there can't be done (anymore) ?
>> 
>> This is more or less how a number of the GNUstep Foundation classes work, using the extra data allocated with class_createInstance() and doing some pointer arithmetic.  Flexible array members would possibly simplify the code, but they’re not needed for this to work.
>> 
>>> I would think a warning would be nice for classes who try to subclass a class with a flexible array ivar if they add another property or ivar.
>> 
>> The problem is that you can’t do this with the non-fragile ABI.  You can write the flexible array member in the @implementation of a class and the person writing the subclass won’t see it.
>> 
>> To make this safe, the minimum set of constraints that you’d need would be:
>> 
>>  - The ivar is the last one
>>  - The ivar is declared in the @interface
>>  - The class does not declare any ivars in the @implementation
>>  - Subclassing a class whose @interface ends with a flexible member is an error
>> 
> 
> That'd mean you couldn't write a subclass that doesn't add an ivar.

That’s true.  Subclasses that don’t add any state should be okay, though this then becomes a bit harder because you need a recursive check that no superclasses end with a fragile array member.

> Or a subclass that overrides the flexible allocation methods but adds some ivars and does something completely else.

This is very fragile, as it relies on knowing that none of the superclass methods will expect the flexible array member to have allocated space and will cause overlapping ivars.

> That's why I think a warning would be nice, but not an error.
> 
> Obviously I am just speaking from my fragile-ABI only perspective :)

I don’t believe that fragile ABI usage should dictate the language, given that existing recent language features (e.g. ivar declarations in @implementations and class extensions) rely on the non-fragile behaviour.

David