Displaying 3 results from an estimated 3 matches for "memcpy_patch".
2012 Oct 03
1
[LLVMdev] Handling of unsafe functions
...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>
2012 Sep 27
0
[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
2012 Sep 21
5
[LLVMdev] Handling of unsafe functions
>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