On Sep 18, 2014, at 4:20 PM, Nico Weber <[email protected]> wrote:
> On Thu, Sep 18, 2014 at 4:11 PM, jahanian <[email protected]> wrote: > > On Sep 18, 2014, at 1:03 PM, Nico Weber <[email protected]> wrote: > >> On Thu, Sep 18, 2014 at 11:38 AM, jahanian <[email protected]> wrote: >> >> On Sep 18, 2014, at 11:33 AM, Reid Kleckner <[email protected]> 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
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
