<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <font face="Helvetica, Arial, sans-serif">Hi JF<br>
      <br>
      Was just wondering how things were going adding these memset_s
      (and the others you mentioned).?<br>
      <br>
      Jonny<br>
      <br>
    </font><br>
    <div class="moz-cite-prefix">On 04/01/2019 20:37, JF Bastien wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:C978F92E-BC8F-4DF8-9F3E-2AE9CEBC09B8@apple.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      I think clang could offer builtins which provide some of the Annex
      K building blocks, and let libc implementations provide the rest
      (using the clang builtins when available).
      <div class=""><br class="">
      </div>
      <div class="">I’m interested in implementing these builtins,
        unless someone beats me to it. User code often uses Annex K to
        provide guarantees that are now redundant with trivial automatic
        variable initialization (<a href="http://llvm.org/rL349442"
          class="" moz-do-not-send="true">llvm.org/rL349442</a>), and
        I’d like to reduce the hit they’re taking. Here are some notes I
        wrote for myself a little while ago:</div>
      <div class=""><br class="">
      </div>
      <blockquote style="margin: 0 0 0 40px; border: none; padding:
        0px;" class="">
        <div class="">
          <div class="">I’ll focus on memset, but this applies to other
            Annex K functionality (memcpy_s, memmove_s, strcpy_s,
            strncpy_s, strcat_s, strncat_s, strtok_s, memset_s,
            strerror_s, strerrorlen_s, strnlen_s).</div>
        </div>
        <div class="">
          <div class=""><br class="">
          </div>
        </div>
        <div class="">
          <div class="">These functions simply perform extra checks
            before calling their regular equivalent, with an extra
            provision that the operation can’t be as-if’d away (i.e. you
            have to do the entire memset).</div>
        </div>
        <div class="">
          <div class=""><br class="">
          </div>
        </div>
        <div class="">
          <div class="">Often, custom memset_s implementations are
            simple loops (cast to char*, and set each byte to 0),
            compiled in a different TU, which, amusingly thought LTO and
            inlining, would totally not obey the “no as-if” rule. Other
            times they’re implemented in opaque assembly.</div>
        </div>
        <div class="">
          <div class=""><br class="">
          </div>
        </div>
        <div class="">
          <div class="">Clang doesn’t know about this function, and
            assumes it’s just another function call. We should tell the
            compiler about what these functions do so that it knows that
            stores prior to memset_s are dead, memset_s can’t be
            removed, what the extra memset_s checks are, and so that we
            can forward values from memset_s. We can then generate
            better code (small loops become stores with a loop, memset_s
            followed by stores get merged, etc).</div>
        </div>
        <div class="">
          <div class=""><br class="">
          </div>
        </div>
        <div class="">
          <div class="">A few options:</div>
        </div>
        <div class="">
          <div class=""><br class="">
          </div>
        </div>
        <div class="">
          <div class="">1. Make them a builtin, have libc
            implementations forward to the builtin.</div>
        </div>
        <div class="">
          <div class="">2. Teach clang / LLVM about these function’s
            semantics (i.e. if conditions met, same as memset).</div>
        </div>
        <div class="">
          <div class="">3. Add an attribute which teaches clang about
            memset-like functions, and use it in libc implementations.</div>
        </div>
        <div class="">
          <div class="">4. Use LTO between the projects and libc
            implementations, allowing clang to peek into memset_s’s
            implementation.</div>
        </div>
        <div class=""><br class="">
        </div>
        <div class="">I think 1. is the best approach.</div>
        <div class=""><br class="">
        </div>
      </blockquote>
      <div class="">
        <div class=""><br class="">
          <div><br class="">
            <blockquote type="cite" class="">
              <div class="">On Jan 4, 2019, at 1:35 AM, Jonny Grant via
                cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org"
                  class="" moz-do-not-send="true">cfe-dev@lists.llvm.org</a>>
                wrote:</div>
              <br class="Apple-interchange-newline">
              <div class="">
                <div class="">Thank you for your reply Richard.<br
                    class="">
                  <br class="">
                  On 03/01/2019 22:04, Richard Smith wrote:<br class="">
                  <blockquote type="cite" class="">On Thu, 3 Jan 2019 at
                    13:44, Jonny Grant via cfe-dev <<a
                      href="mailto:cfe-dev@lists.llvm.org" class=""
                      moz-do-not-send="true">cfe-dev@lists.llvm.org</a>
                    <<a href="mailto:cfe-dev@lists.llvm.org" class=""
                      moz-do-not-send="true">mailto:cfe-dev@lists.llvm.org</a>>>
                    wrote:<br class="">
                       Hello<br class="">
                       This file lists part of Annex K  "stdint.h"<br
                      class="">
                       <a
                      href="https://clang.llvm.org/doxygen/stdint_8h_source.html"
                      class="" moz-do-not-send="true">https://clang.llvm.org/doxygen/stdint_8h_source.html</a><br
                      class="">
                       But main C++ page doesn't mention Annex K. Is
                    Annex K really fully<br class="">
                       supported?<br class="">
                    That's generally not up to us; that's part of the C
                    standard library, not part of the compiler.<br
                      class="">
                    The one part of Annex K that *is* part of the
                    compiler, according to the usual division of
                    responsibilities, wherein the compiler provides the
                    freestanding headers and the C standard library
                    provides the rest, is the definition of rsize_t in
                    <stddef.h> and the definition of RSIZE_MAX in
                    <stdint.h>, and Clang provides those if
                    __STDC_WANT_LIB_EXT1__ is defined. However, we do
                    not define __STDC_LIB_EXT1__ because, as noted,
                    that's not up to us, and we have no idea what your C
                    standard library supports.<br class="">
                  </blockquote>
                  <br class="">
                  I use glibc, it doesn't support Annex K. We are keen
                  to use Annex K functionality, so looking around for
                  options.<br class="">
                  <br class="">
                  Do you know if Clang has any intention to develop
                  support for a libc C11 with Annex K Support?<br
                    class="">
                  <br class="">
                  <br class="">
                  I'm looking around, and came across this project<br
                    class="">
                  <a
                    href="https://github.com/rurban/safeclib/blob/master/README"
                    class="" moz-do-not-send="true">https://github.com/rurban/safeclib/blob/master/README</a><br
                    class="">
                  <br class="">
                  <br class="">
                  <blockquote type="cite" class="">So in that sense, we
                    implement the part of Annex K that is in our domain.<br
                      class="">
                       Some background<br class="">
                       <a class="moz-txt-link-freetext"
                      href="https://clang.llvm.org/compatibility.html"
                      moz-do-not-send="true">https://clang.llvm.org/compatibility.html</a><br
                      class="">
                       <a class="moz-txt-link-freetext"
                      href="https://clang.llvm.org/cxx_status.html"
                      moz-do-not-send="true">https://clang.llvm.org/cxx_status.html</a><br
                      class="">
                    I'm not sure what these are supposed to show: Annex
                    K is optional in C, and not part of C++.<br class="">
                  </blockquote>
                  <br class="">
                  It would be good if what you state could be added to
                  the compatibility page, that Annex K is supported only
                  for stdint.h, but that clang requires a libc which
                  supports C11 Annex K functions/implementation.<br
                    class="">
                  <br class="">
                  Cheers, Jonny<br class="">
                  <br class="">
                  <br class="">
                  _______________________________________________<br
                    class="">
                  cfe-dev mailing list<br class="">
                  <a class="moz-txt-link-abbreviated"
                    href="mailto:cfe-dev@lists.llvm.org"
                    moz-do-not-send="true">cfe-dev@lists.llvm.org</a><br
                    class="">
                  <a class="moz-txt-link-freetext"
                    href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev"
                    moz-do-not-send="true">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br
                    class="">
                </div>
              </div>
            </blockquote>
          </div>
          <br class="">
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>