<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:x="urn:schemas-microsoft-com:office:excel" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" 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=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","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;}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";}
@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"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">From the responses it’s pretty clear that the preference is to avoid using C string functions altogether. I’ve attached at list of calls in Clang/LLVM. The
 EASY/MEDIUM/DIFFICULT tag is an estimate of the effort to replace the call based on the location of the source buffer. If there are no objections I’ll prepare a patch that replaces the string manipulation functions an appropriate  string object.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The proposal comments have largely centered on the string functions. Do people feel the same way about memcpy_s? What about those of you building LLVM on Windows
 with Visual Studio?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I know both functions can be used the wrong way but at least the “secure” version makes one think about the value passed for destination size. Very likely most
 of the 1691 uses of memcpy in Clang/LLVM are correct but with such a high number of uses there are likely a few that are not. I’m willing to plow through all the calls to check the parameters while making the change to the memcpy_secure version from the proposal.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Javier<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> llvmdev-bounces@cs.uiuc.edu [mailto:llvmdev-bounces@cs.uiuc.edu]
<b>On Behalf Of </b>Richard Smith<br>
<b>Sent:</b> Thursday, September 20, 2012 3:09 PM<br>
<b>To:</b> Chris Lattner<br>
<b>Cc:</b> llvmdev@cs.uiuc.edu<br>
<b>Subject:</b> Re: [LLVMdev] Handling of unsafe functions<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">On Thu, Sep 20, 2012 at 10:13 AM, Chris Lattner <<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>> wrote:<o:p></o:p></p>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
On Sep 20, 2012, at 3:01 AM, Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>> wrote:<br>
<br>
> On Wed, Sep 19, 2012 at 3:00 AM, Martinez, Javier E<br>
> <<a href="mailto:javier.e.martinez@intel.com">javier.e.martinez@intel.com</a>> wrote:<br>
>> We have identified functions in LLVM sources using a static code analyzer<br>
>> which are marked as a “security vulnerability”[1][2]. There has been work<br>
>> already done to address some of them for Linux (e.g. snprintf). We are<br>
>> attempting to solve this issue in a comprehensive fashion across all<br>
>> platforms. Most of the functions identified are for manipulating strings.<br>
>> Memcpy is the most commonly used of all these unsecure methods. The<br>
>> following table lists all these functions are their recommended secure<br>
>> alternatives.<br>
><br>
> I am strongly opposed to using *_s functions.  The issue is that they<br>
> are no more "secure" than original functions.  One can still pass the<br>
> destination buffer length incorrectly, especially if it is not known<br>
> at compile time and should be computed.<br>
><br>
> I agree with Sean that we should move the code using C strings to LLVM<br>
> safe data types.<o:p></o:p></p>
</div>
<p class="MsoNormal">I agree.<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
><br>
> And one more thing: it is interesting that the "unsafe"<br>
> APFloat::convertToHexString (from your patch) is not used anywhere.<o:p></o:p></p>
</div>
<p class="MsoNormal">Zap it!  Oh wait, is it used by Clang or something else?<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Clang doesn't use it, but LLDB does, with an arbitrary-seeming 256-character buffer. Perhaps we should change it to take an llvm::SmallVectorImpl<char>, rather than relying on a character buffer "which must be of sufficient size".<o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>