<div dir="ltr"><div dir="ltr"><div>Long time Annex K observer here: I would just like to add my 2 cents.</div><div><br></div><div>I would <i><b>very </b></i>much like to see some kind of minimal compiler support for the bounds checking functions - memcpy_s, memmove_s, strcpy_s, strncpy_s, strcat_s - since overruns in their non-bounds-checked equivalents have been responsible for hundreds of security vulnerabilities over the years. It doesn't have to be fully annex K compliant for my concerns, just has to obey the buffer boundaries. Some kind of minimal compiler support would also make cross platform programming much easier, since as of right now I use the bounds checking versions in code compiled for MSVC, and have to either #ifdef it out or lose the extra checking.</div><br clear="all"><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><span style="font-size:12.8px">Sincerely,</span><br style="font-size:12.8px"><span style="font-size:12.8px">Alexander Riccio</span><br style="font-size:12.8px"><span style="font-size:12.8px">--</span><br style="font-size:12.8px"><span style="font-size:12.8px">"Change the world or go home."</span><div style="font-size:12.8px"><a href="http://about.me/ariccio" target="_blank">about.me/ariccio</a></div><div style="font-size:12.8px"><a href="http://about.me/ariccio" target="_blank"><br></a></div><div style="font-size:12.8px">If left to my own devices, I will build more.</div><div style="font-size:12.8px">⁂</div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 3, 2019 at 12:07 PM JF Bastien via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"></div><div dir="ltr"><br></div><div dir="ltr">On Mar 3, 2019, at 7:46 AM, Jonny Grant <<a href="mailto:jg@jguk.org" target="_blank">jg@jguk.org</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr">
<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></font></div></blockquote><div><br></div><div>I haven’t started. It’s on my short list of things to do. </div><div><br></div><br><blockquote type="cite"><div dir="ltr"><font face="Helvetica, Arial, sans-serif">
Jonny<br>
<br>
</font><br>
<div class="gmail-m_3844651895306944121moz-cite-prefix">On 04/01/2019 20:37, JF Bastien wrote:<br>
</div>
<blockquote type="cite">
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><br>
</div>
<div>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" target="_blank">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><br>
</div>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div>
<div>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>
<div><br>
</div>
</div>
<div>
<div>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>
<div><br>
</div>
</div>
<div>
<div>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>
<div><br>
</div>
</div>
<div>
<div>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>
<div><br>
</div>
</div>
<div>
<div>A few options:</div>
</div>
<div>
<div><br>
</div>
</div>
<div>
<div>1. Make them a builtin, have libc
implementations forward to the builtin.</div>
</div>
<div>
<div>2. Teach clang / LLVM about these function’s
semantics (i.e. if conditions met, same as memset).</div>
</div>
<div>
<div>3. Add an attribute which teaches clang about
memset-like functions, and use it in libc implementations.</div>
</div>
<div>
<div>4. Use LTO between the projects and libc
implementations, allowing clang to peek into memset_s’s
implementation.</div>
</div>
<div><br>
</div>
<div>I think 1. is the best approach.</div>
<div><br>
</div>
</blockquote>
<div>
<div><br>
<div><br>
<blockquote type="cite">
<div>On Jan 4, 2019, at 1:35 AM, Jonny Grant via
cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>
wrote:</div>
<br class="gmail-m_3844651895306944121Apple-interchange-newline">
<div>
<div>Thank you for your reply Richard.<br>
<br>
On 03/01/2019 22:04, Richard Smith wrote:<br>
<blockquote type="cite">On Thu, 3 Jan 2019 at
13:44, Jonny Grant via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>
<<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">mailto:cfe-dev@lists.llvm.org</a>>>
wrote:<br>
Hello<br>
This file lists part of Annex K "stdint.h"<br>
<a href="https://clang.llvm.org/doxygen/stdint_8h_source.html" target="_blank">https://clang.llvm.org/doxygen/stdint_8h_source.html</a><br>
But main C++ page doesn't mention Annex K. Is
Annex K really fully<br>
supported?<br>
That's generally not up to us; that's part of the C
standard library, not part of the compiler.<br>
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>
</blockquote>
<br>
I use glibc, it doesn't support Annex K. We are keen
to use Annex K functionality, so looking around for
options.<br>
<br>
Do you know if Clang has any intention to develop
support for a libc C11 with Annex K Support?<br>
<br>
<br>
I'm looking around, and came across this project<br>
<a href="https://github.com/rurban/safeclib/blob/master/README" target="_blank">https://github.com/rurban/safeclib/blob/master/README</a><br>
<br>
<br>
<blockquote type="cite">So in that sense, we
implement the part of Annex K that is in our domain.<br>
Some background<br>
<a class="gmail-m_3844651895306944121moz-txt-link-freetext" href="https://clang.llvm.org/compatibility.html" target="_blank">https://clang.llvm.org/compatibility.html</a><br>
<a class="gmail-m_3844651895306944121moz-txt-link-freetext" href="https://clang.llvm.org/cxx_status.html" target="_blank">https://clang.llvm.org/cxx_status.html</a><br>
I'm not sure what these are supposed to show: Annex
K is optional in C, and not part of C++.<br>
</blockquote>
<br>
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>
<br>
Cheers, Jonny<br>
<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a class="gmail-m_3844651895306944121moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a class="gmail-m_3844651895306944121moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</div></blockquote></div>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>