[cfe-dev] Flexible array members in ObjC classes

[John McCall via cfe-dev]

> On Sep 21, 2017, at 12:04 PM, Volodymyr Sapsai <vsapsai at apple.com> wrote:
> On Sep 21, 2017, at 10:07, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
>> 
>>> On Sep 21, 2017, at 1:30 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk <mailto:David.Chisnall at cl.cam.ac.uk>> wrote:
>>> On 21 Sep 2017, at 02:51, John McCall via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>>>> 
>>>> Objective-C objects are allocated dynamically, and it's absolutely possible to allocate extra storage in an object and then access that via a trailing flexible or zero-length array.  It is, of course, somewhat perilous, but that's true of flexible/zero-length array members of structs, too.
>>> 
>>> This is a lot more perilous with the non-fragile ABI.  In classical Objective-C, classes were lowered to structs and so all of these tricks were used (indeed, allocating objects with extra space was explicitly supported by all of the common allocation mechanisms).  Adding a flexible array member at the end was not a problem, because anyone subclassing your class could see the structure layout in the header and know that subclassing was probably dangerous.
>>> 
>>> The only place where it should be allowed at all is in the last ivar in a class, and the only place it should be allowed in the non-fragile ABI is the last ivar of a class that cannot be subclassed (which, given that objc_subclassing_restricted doesn’t seem to be documented and is not supported by older compilers, is not something that’s easy to enforce).
>> 
>> Yeah, I don't think we can reasonably enforce anything about subclasses, except maybe warning if we see that we're adding an ivar (explicitly or via synthesis) to a class that's known to have a flexible array member.  Of course that means that the protection will be incomplete.
>> 
>> John.
> 
> Thanks everybody for their input. I plan to update the patch with different test cases so it's easier to discuss. But so far my summary is the following.
> 
> For flexible array members we allow them only as the last ivar in @interface, with no ivars in @implementation. If it's not last, if it is in @implementation, if there are more ivars in @implementation - that's an error.
> 
> For variable sized types (i.e. structs with last member a flexible array) we don't error but warn if we can detect more ivars after it (in @interface or in @implementation). If @implementation ivars end with variable sized ivar, no error or warning.
> 
> For subclassing we don't error but warn if we can detect more ivars after a flexible array member or after a variable sized type member.

I think most of this sounds reasonable.  I would recommend being lax about whether the ivar is declared in the @interface vs. the @implementation, though.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170921/877fa4ac/attachment.html>