[cfe-dev] Flexible array members in ObjC classes

Jean-Daniel via cfe-dev cfe-dev at lists.llvm.org
Sun Sep 24 02:40:18 PDT 2017



> Le 21 sept. 2017 à 11:14, David Chisnall via cfe-dev <cfe-dev at lists.llvm.org> a écrit :
> 
> 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

And make the class fragile, which is probably not what you want it you use non-fragile ABI in the first place.

The goal of the non-fragile ABI is to be able to add ivar retroactively without breaking subclasses. That goal will not be possible with flexible array so they should not be allowed in anything but ‘final’ class IMHO.

If someone want to use that kind of risky trick, it should not use ivar in the first place, but override the +alloc method and perform pointer arithmetic to get a pointer on the extra storage. It will not be safer, but at least it will be explicit.




More information about the cfe-dev mailing list