[LLVMdev] Handling of unsafe functions

[Martinez, Javier E]

Florian,

You have a valid point, the majority of the times memcpy is used correctly and the destination buffer size is redundant information. I think we also agree that there are cases where the correct use of memcpy is not clear cut and the 4-parameter version adds value.

I've modified the original proposal to strike the middle of the road. Instead of only providing a 4-parameter version of memcpy_secure now a 3-parameter version also exists. The latter maps to memcpy or memcpy_s depending on what's available as determined by the CMake scripts. The 4-parameter version replaces those calls to memcpy where safe use can't be determined. All other calls will be replaced to the 3-parameter version.

This solution avoids passing redundant information, covers the situation where additional checking is of value and is platform independent (except for the implementation of memcpy_secure). The attached patch demonstrates the idea.

Thanks,
Javier

-----Original Message-----
From: Florian Weimer [mailto:fweimer at redhat.com] 
Sent: Thursday, September 27, 2012 5:26 AM
To: Martinez, Javier E
Cc: Richard Smith; Chris Lattner; llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Handling of unsafe functions

On 09/21/2012 05:52 AM, Martinez, Javier E wrote:

> 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?

Is memcmp_s (or a variant thereof) a win in practice?  It covers the case pretty well where you try to copy a dynamically sized buffer to the start of a statically sized one.  I don't want to say that it doesn't happen, but it seems to be rather rare, and I expect most calls to memcpy_s would use the same expression for both sizes.

-- 
Florian Weimer / Red Hat Product Security Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: memcpy_patch.patch
Type: application/octet-stream
Size: 5337 bytes
Desc: memcpy_patch.patch
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121003/361da83d/attachment.obj>