r218063 - Patch to check at compile time for overflow when

[jahanian]

On Sep 18, 2014, at 4:20 PM, Nico Weber <thakis at chromium.org> wrote:

> On Thu, Sep 18, 2014 at 4:11 PM, jahanian <fjahanian at apple.com> wrote:
> 
> On Sep 18, 2014, at 1:03 PM, Nico Weber <thakis at chromium.org> wrote:
> 
>> On Thu, Sep 18, 2014 at 11:38 AM, jahanian <fjahanian at apple.com> wrote:
>> 
>> On Sep 18, 2014, at 11:33 AM, Reid Kleckner <rnk at google.com> wrote:
>> 
>> > Cool! Do these warnings fire on plain memcpy if the system headers don't arrange for memcpy to route to __builtin__memcpy_chk? If so, can you add tests for plain prototyped memcpy as you did for strlcpy in the previous test?
>> >
>> 
>> No they don’t. Note that __builtin__memcpy_chk, etc. will have an added argument,  __builtin_object_size,  which will have
>> the size of destination buffer and is needed to do the checking.
>> 
>> But you can just call the code that does the computation that __builtin_object_size does when checking memcpy, right?
> 
> I am not sure what you mean. memcpy does not do any checking for overflow. You may do the checking for overflow before calling
> memcpy yourself (essentially do what __builtin_memcpy_chk does).
> 
> But it's detectable at compile time, right? Consider this, slightly changed from your tests:
> 
>   static char buf[10];
>   memcpy(&buf[6], in, 5);
> 
> Is there any reason this shouldn't say "memcpy will always overflow destination buffer”?


On the surface there is no reason. But manage does not disallow this and there will be applications which probably take advantage of this relaxation.

- fariborz


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140918/b9a8652f/attachment.html>