<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/7/22 1:23 AM, Bryce Wilson via
      llvm-dev wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:A4D67170-54F6-45AC-BF1A-7FF69488E377@thenetworknerds.ca">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode:
        space; line-break: after-white-space;" class="">
        <div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode:
          space; line-break: after-white-space;" class="">
          <div class="">Hi all,</div>
          <div class=""><br class="">
          </div>
          <div class="">It's quite a coincidence to see this proposal. I
            just joined this list a few days ago specifically to ask
            about the correct way to annotate allocation and freeing
            functions. <span style="color: rgb(0, 0, 0);" class="">I'll
              create a separate thread to ask questions about my
              specific situation but I wanted to add my support for this
              proposal here.</span></div>
          <div class=""><font class="" color="#000000"><br class="">
            </font></div>
          <div class=""><font class="" color="#000000">My main question
              is if there should be some way to specify the kind of
              allocation function. In the hardcoded AllocationFnData
              array, there is a field to specify if the function acts
              like malloc, new, calloc, realloc, etc. This could be
              added to the annotation but I think a better way would be
              to specify the actual properties of interest. Can it
              return null, does it align the allocation, and what are
              the values in the newly allocated space (undef for malloc,
              0 for calloc, something unknown but defined for <span
                style="caret-color: rgb(0, 0, 0);" class="">strdup).
                This would also allow for creating new types of
                allocators that don't already exist.</span></font></div>
        </div>
      </div>
    </blockquote>
    <p>Bryce, I completely agree with this property based approach.  In
      fact, I've spent the last day or so landing patches which move us
      in exactly that direction.  Unfortunately, I think a good amount
      of your patch is now redundant, but if you wanted to swap notes on
      remaining things to fix, please feel free to ping me directly. 
      I'll also start adding you on reviews where appropriate.</p>
    <p>One subtle but important point: we do not want to have any
      property of an allocation function which can be expressed with
      existing attributes.  So, for instance, we do not want code to be
      dependent on throwing operator new never returning null.  Instead,
      we want said functions annotated nonnull, and the generic code to
      drive the optimization.  <br>
    </p>
    <blockquote type="cite"
      cite="mid:A4D67170-54F6-45AC-BF1A-7FF69488E377@thenetworknerds.ca">
      <div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode:
        space; line-break: after-white-space;" class="">
        <div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode:
          space; line-break: after-white-space;" class="">
          <div class=""><font class="" color="#000000"><span
                style="caret-color: rgb(0, 0, 0);" class=""><br class="">
              </span></font></div>
          <div class=""><font class="" color="#000000">I've created a
              patch with what this might look like for the existing
              hardcoded functions here: </font><a
              href="https://reviews.llvm.org/D116797" class=""
              moz-do-not-send="true">https://reviews.llvm.org/D116797</a><font
              class="" color="#000000">. In my initial implementation, I
              realized that there are a lot of places where argument
              positions are hardcoded and special detection of strdup
              and strndup is hardcoded. Regardless of if we add
              the ability to specify these properties in attribute form
              or not, we will at least need to ensure that the correct
              arguments are used based on an allocsize annotation if <span
                style="caret-color: rgb(0, 0, 0);" class="">available</span>.</font></div>
        </div>
      </div>
    </blockquote>
    I think I've already killed several of the ones you note.  I agree
    there's definite room to improve the handling of strdup/strndup.  If
    you wanted to write a patch for that specifically, I'd be happy to
    review.  <br>
    <blockquote type="cite"
      cite="mid:A4D67170-54F6-45AC-BF1A-7FF69488E377@thenetworknerds.ca">
      <div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode:
        space; line-break: after-white-space;" class="">
        <div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode:
          space; line-break: after-white-space;" class="">
          <div class=""><font class="" color="#000000"><br class="">
            </font></div>
          <div class="">
            <div>Sincerely,<br class="">
              Bryce Michael Wilson</div>
          </div>
          <br class="">
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
    </blockquote>
  </body>
</html>