[cfe-dev] Flexible array members in ObjC classes

Volodymyr Sapsai via cfe-dev cfe-dev at lists.llvm.org
Thu Sep 21 12:04:49 PDT 2017


On Sep 21, 2017, at 10:07, John McCall <rjmccall at apple.com> wrote:
> 
>> On Sep 21, 2017, at 1:30 AM, David Chisnall <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> 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.

Thanks,
Volodymyr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170921/0d55bec7/attachment.html>


More information about the cfe-dev mailing list