<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 09.03.2013 5:01, Jordan Rose wrote:<br>
</div>
<blockquote
cite="mid:88BADB1F-1402-41A0-9D1C-5D125DCBBBA2@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<div>
<div>On Mar 8, 2013, at 15:06 , Anton Yartsev <<a
moz-do-not-send="true" href="mailto:anton.yartsev@gmail.com">anton.yartsev@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF" style="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;">
<div class="moz-cite-prefix">On 09.03.2013 2:51, Anton
Yartsev wrote:<br>
</div>
<blockquote cite="mid:513A6B5F.8040709@Gmail.com"
type="cite">
<div class="moz-cite-prefix">On 08.03.2013 23:25, Jordan
Rose wrote:<br>
</div>
<blockquote
cite="mid:6FEFB13F-E234-4057-83A1-976596FA2A10@apple.com"
type="cite"><br>
<div>
<div>On Mar 8, 2013, at 11:22 , Anna Zaks <<a
moz-do-not-send="true"
href="mailto:ganna@apple.com">ganna@apple.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<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<span class="Apple-converted-space"> </span><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>
</blockquote>
Aaaa, got it!<br>
Updated the patch.<br>
<br>
<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>></div>
<div>> Case 2: The selector contains "freeWhenDone",
which is set to '0'. </div>
<div>> The call results in no escape of the pointer.</div>
<div>></div>
<div>> Case 3: Otherwise (this is not Case 1 nor Case
3) and the selector ends with "NoCopy"</div>
<div>> The pointer should escape.</div>
<div>></div>
<div>> Please, work off your previous patch, but change
the logic to handle these cases and include the tests.
Also, I think it's<span class="Apple-converted-space"> </span><br>
> important to include a commit message with your
patch so that there would be no ambiguity in what the
patch is trying to accomplish.<br>
> Usually, the commit message and the tests would
resolve that.<br>
I'll put this cases in a commit message.<br>
</div>
<pre class="moz-signature" cols="72">--
Anton</pre>
</blockquote>
Or even with a better name for doesNotFreeMemory() and
comment.<br>
</div>
</blockquote>
</div>
<br>
<div>Thanks, Anton; committed in r176744! We thought of another
test case and so I had to restructure it a bit, but I think
after rebasing we can move forward with your main patch.</div>
<div><br>
</div>
<div>Jordan</div>
</blockquote>
<br>
Attached is an updated patch.<br>
<br>
<pre class="moz-signature" cols="72">--
Anton</pre>
</body>
</html>