search for: ms235384

Displaying 4 results from an estimated 4 matches for "ms235384".

2012 Sep 19
7
[LLVMdev] Handling of unsafe functions
...one function refactoring. The attached patch helps illustrate how an instance of memcpy would be modified. Is this proposal of interest to the LLVM community? Can you also comment if the approach specified is good to address this issue? References: [1] http://msdn.microsoft.com/en-us/library/ms235384(v=vs.80).aspx [2] https://developer.apple.com/library/mac/#documentation/Security/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120919/7de4688a/at...
2012 Sep 19
0
[LLVMdev] Handling of unsafe functions
...ps illustrate how an instance of memcpy would be modified. > > > > Is this proposal of interest to the LLVM community? Can you also comment if > the approach specified is good to address this issue? > > > > References: > > [1] http://msdn.microsoft.com/en-us/library/ms235384(v=vs.80).aspx > > [2] > https://developer.apple.com/library/mac/#documentation/Security/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llv...
2012 Sep 19
0
[LLVMdev] Handling of unsafe functions
...ing llvm::report_fatal_error and hoping we don't recurse? What if it's a debug build and we'd like to see where the code went wrong? How do you plan to enforce that the insecure functions aren't called? Nick > References: > > [1] http://msdn.microsoft.com/en-us/library/ms235384(v=vs.80).aspx > > [2] > https://developer.apple.com/library/mac/#documentation/Security/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu...
2012 Sep 20
1
[LLVMdev] Handling of unsafe functions
...s illustrate how an instance of memcpy would be modified. > > > > Is this proposal of interest to the LLVM community? Can you also > comment if the approach specified is good to address this issue? > > > > References: > > [1] http://msdn.microsoft.com/en-us/library/ms235384(v=vs.80).aspx > > [2] > https://developer.apple.com/library/mac/#documentation/Security/Concep > tual/SecureCodingGuide/Articles/BufferOverflows.html > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http...