<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jun 25, 2008, at 10:34 PM, Nikita Zhuk wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div>I noticed that you've added the support for self-owning objects into lib/Analysis/CFRefCount.cpp in r52741. Thanks! I guess that commit was the "longer response" you were talking about.</div></span></blockquote><div><br></div><div>I actually was planning on following up with you with an email after testing that patch further. Does it silence the false warnings? (at least in the case of NSWindow and its subclasses)</div><div><br></div><div>I was also investigating other issues that you mentioned; e.g. delegates. I'm not an Objective-C applications programmer, so while I understand much of the concepts and the common idioms, I'm lazily learning much of the common design practices. This makes feedback like yours especially useful.</div><div><br></div><div>What would help me with such feedback is to always provide concrete code examples. These give me a clear idea of what to implement in the static analyzer, and it provides test cases we can put into the test suite.</div><div><br></div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div><span class="Apple-style-span" style="color: rgb(20, 79, 174); -webkit-text-stroke-width: -1; ">Are there any plans to generalize this checking logic so it could be used with other classes than NSWindow? In my own source code I have several classes which use similar self-ownership semantics as NSWindow, and it would be nice to avoid getting false memory leak reports for objects of those classes.</span></div></span></blockquote><div><br></div><div><br></div><div>Absolutely. My thought is that we can implement an attribute that can be affixed to the class interface. I would need to implement parsing support for this in clang, but essentially it would something like this:</div><div><br></div><div><div>__attribute__((checker("objc_owns_self"))) @interface .... @end</div><div><br></div><div>Of course GCC doesn't recognize the attribute, so it could be wrapped in a macro:</div><div><br></div><div>#if __clang__</div><div>#define OBJC_OWNS_SELF __attribute__((checker("objc_owns_self")))</div><div>#else</div><div>#define OBJC_OWNS_SELF</div><div>#endif</div></div><div><br></div><div>and do the following in your code:</div><div><br></div><div>OBJC_OWNS_SELF</div><div>@interface ....</div><div>@end</div><div><br></div><div>Does this sound like a reasonable strategy? Your feedback is invaluable here. (you're basically driving this feature!)</div><div><br></div><div>What would help me is also some code examples illustrating the idiom of self-ownership. That way I know I'm solving the right problem.</div><div><br></div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div>As completely offtopic question, does cfe-dev mailing list has some rules which specify when one should reply to mailing list and when to reply just directly to the original poster? I didn't find any rules at general mailing list page at [1]. I've seen both behaviors, and I would like to follow the correct one. </div><div><br></div><div>[1] <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a></div><div><br></div><div>- Nikita</div></span></blockquote><br></div><div>I think the rule of thumb is to keep a conversation on the list, so that it is archived and allows other people to wade in. As long as the conversation stays clang related it is on-topic. I take things off list when it comes down to issues only involving two people (e.g., how to send a particular patch over email to a specific person, etc.). Most of the time the communication can be on the list itself. For example, the email that you just sent me could have gone directly to the list as is. In fact, I've CC'ed cfe-dev on this reply so that this can again become an active thread.</div><div><br></div><div>Best,</div><div>Ted</div></body></html>