
<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Mar 8, 2013, at 11:22 , Anna Zaks <<a href="mailto:ganna@apple.com">ganna@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Anton,<div><br></div><div>We've briefly discussed this with Jordan. Below are the cases we should handle:</div><div><br></div><div>Case 1: The selector starts with "<span style="color: rgb(209, 47, 27); font-family: Menlo;">dataWithBytesNoCopy</span>" or "<span style="color: rgb(209, 47, 27); font-family: Menlo;">initWithBytesNoCopy</span>" or "<span style="color: rgb(209, 47, 27); font-family: Menlo;">initWithCharactersNoCopy</span>" and "freeWhenDone" is not set to "0".</div><div>We should assume that the call preforms hold action from malloc family. (So the pointer should not escape and we should model this during ObjCMsgCall processing)</div></div></blockquote><br>To explain the rationalization here, Anna pointed out that while it's <i>likely</i> that methods with a "freeWhenDone:" or "...NoCopy:" selector piece all behave as ownership-holders, we can't actually prove it. In particular, if/when MallocChecker gains the ability to reason about custom allocators, someone could very well use "...NoCopy" to mean "I will free this using my custom deallocator", and we don't want to produce a bogus allocator mismatch bug in that case.</div><div><br></div><div>By the way, by "the selector starts with __", we mean the existing logic of "the first selector piece is __", not "the first selector piece starts with __".</div><div><br></div><div>Thanks for bearing with us.</div><div>Jordan</div></body></html>