<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Providing the primitives for memset_s would be great. It is a genuinely useful part of Annex K. I will note that the majority of Annex K is of little practical use though, due to the global (not thread local) customizable constraint handler.
set_constraint_handler_s and friends don’t play nice when you don’t control the entire codebase / process, especially in multithreaded situations.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> cfe-dev <cfe-dev-bounces@lists.llvm.org> <b>On Behalf Of
</b>JF Bastien via cfe-dev<br>
<b>Sent:</b> Friday, January 4, 2019 2:38 PM<br>
<b>To:</b> Jonny Grant <jg@jguk.org><br>
<b>Cc:</b> Richard Smith <richard@metafoo.co.uk>; cfe-dev <cfe-dev@lists.llvm.org><br>
<b>Subject:</b> Re: [cfe-dev] C++ Annex K safe C11 functions<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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).<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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="https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_rL349442&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=47CUce2KD-8romOMV1c0n3Jf1FmDdTav65Z7IhLfqCA&s=xnoaNTYQB5AG7H3ePoLmv3__tTk2xUXiGPzSJUUWyO8&e=">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:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="margin-left:30.0pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">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).<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">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).<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">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).<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">A few options:<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">1. Make them a builtin, have libc implementations forward to the builtin.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">2. Teach clang / LLVM about these function’s semantics (i.e. if conditions met, same as memset).<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">3. Add an attribute which teaches clang about memset-like functions, and use it in libc implementations.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">4. Use LTO between the projects and libc implementations, allowing clang to peek into memset_s’s implementation.<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I think 1. is the best approach.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Jan 4, 2019, at 1:35 AM, Jonny Grant via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Thank you for your reply Richard.<br>
<br>
On 03/01/2019 22:04, Richard Smith wrote:<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">On Thu, 3 Jan 2019 at 13:44, Jonny Grant via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a> <<a href="mailto:cfe-dev@lists.llvm.org">mailto:cfe-dev@lists.llvm.org</a>>> wrote:<br>
Hello<br>
This file lists part of Annex K "stdint.h"<br>
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__clang.llvm.org_doxygen_stdint-5F8h-5Fsource.html&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=47CUce2KD-8romOMV1c0n3Jf1FmDdTav65Z7IhLfqCA&s=Z-lwudemttLy91BrXNFBz8l2yiW953ujD9xCv2y2F7U&e=">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.<o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_rurban_safeclib_blob_master_README&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=47CUce2KD-8romOMV1c0n3Jf1FmDdTav65Z7IhLfqCA&s=PojgXc2R9m6hVptb1OkezkCCDk_bxurPoBN_z2Pmxt0&e=">https://github.com/rurban/safeclib/blob/master/README</a><br>
<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">So in that sense, we implement the part of Annex K that is in our domain.<br>
Some background<br>
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__clang.llvm.org_compatibility.html&d=DwQFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=47CUce2KD-8romOMV1c0n3Jf1FmDdTav65Z7IhLfqCA&s=bR0kbW7hLzG2fYggkdi0Y6AG7ABPvi1c_6tpbw37OH4&e=">https://clang.llvm.org/compatibility.html</a><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__clang.llvm.org_cxx-5Fstatus.html&d=DwQFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=47CUce2KD-8romOMV1c0n3Jf1FmDdTav65Z7IhLfqCA&s=EBD4SY7xJtvHQ5eZUDripUykVdQcelJbp_Pr6SbeaM4&e=">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++.<o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><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 href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Ddev&d=DwQFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=47CUce2KD-8romOMV1c0n3Jf1FmDdTav65Z7IhLfqCA&s=linKyptHUpLGIPZ5kBP4LxKNcShSeh35ASViGFRNI0A&e=">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>