<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 2:51, Anton Yartsev
      wrote:<br>
    </div>
    <blockquote cite="mid:513A6B5F.8040709@Gmail.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <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">
        <meta http-equiv="Content-Type" content="text/html;
          charset=ISO-8859-1">
        <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">
            <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>
      </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 <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>
    <br>
    <pre class="moz-signature" cols="72">-- 
Anton</pre>
  </body>
</html>