On Tue, Oct 28, 2014 at 1:21 AM, Maxim Ostapenko <m.ostape...@partner.samsung.com> wrote: > >>> The code which identifies interceptors seems to be duplicated in >>> expand_builtin. What about factoring this out to some >>> is_asan_intercepted() >>> in asan.h? >> >> I agree. > > > Fixed this. >> >> >> BTW, when you handle a builtin, but set *intercepted_p to false, is the >> point just that you don't instrument e.g. scalar accesses to that memory >> region afterwards? I mean: >> memcpy (p, "abc", 3); >> p[0] = 'd'; >> you don't really have to instrument p[0] store, because supposedly memcpy >> call has already verified p[0] through p[2] is writable. >> >> Jakub >> > > Yes, in this case p[0] store is not instrumented we use either intercepted_p > builtin or not intercepted_p one. But access with some offset e.g. to p[1] > will be instrumented in both cases. I'll probably fix this next time. > > As Yury mentioned, I've also added a test case for pr63638 in this patch. > > Tested on x86_64-unknown-inux-gnu. > > -Maxim
Your checkin: https://gcc.gnu.org/ml/gcc-cvs/2014-10/msg01046.html contains changes to c-c++-common/asan/strlen-overflow-1.c which isn't listed in ChangeLog. -- H.J.
