[LLVMdev] Handling of unsafe functions
Martinez, Javier E
javier.e.martinez at intel.com
Tue Oct 2 23:30:00 PDT 2012
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.
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...
Size: 5337 bytes
More information about the llvm-dev