<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Sep 21, 2017, at 12:04 PM, Volodymyr Sapsai <<a href="mailto:vsapsai@apple.com" class="">vsapsai@apple.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Sep 21, 2017, at 10:07, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:<br class=""><div class=""><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div style="" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">On Sep 21, 2017, at 1:30 AM, David Chisnall <<a href="mailto:David.Chisnall@cl.cam.ac.uk" class="">David.Chisnall@cl.cam.ac.uk</a>> wrote:<br class="">On 21 Sep 2017, at 02:51, John McCall via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""><blockquote type="cite" class=""><br class="">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.<br class=""></blockquote><br class="">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.<br class=""><br class="">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).<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">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.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">John.</span></div></div></blockquote><br class=""></div><div class=""><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div></div></div></div></blockquote><div><br class=""></div></div>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.<div class=""><br class=""></div><div class="">John.</div></body></html>