[PATCH] D17891: [sanitizer] Fix strlen assumptions in sanitizer interception code

[Derek Bruening via llvm-commits]

On Fri, Mar 4, 2016 at 2:34 PM, Kostya Serebryany <kcc at google.com> wrote:

>
> On Fri, Mar 4, 2016 at 11:32 AM, Derek Bruening <bruening at google.com>
> wrote:
>
>> bruening added a comment.
>>
>> What if instead we moved the strlen interceptors that are currently
>> private to asan, tsan, and msan into the set of common interceptors, thus
>> ensuring that REAL(strlen) exists (as well as unifying the currently
>> duplicate interceptors)?  I actually already have a local CL that moves
>> strlen and strchr* into the common set which I can send for review.
>>
> In most cases such unification is more than welcome!
> (Just need to be careful not to lose any functionality)
>

Putting more into the common set will make it easier to add new tools as
well.

Perhaps you could give your thoughts on some of the complexities involved:

   - Are you ok with asan's replace_str flag applying not just to "string
   routines" but also to string-typed parameters (e.g., the first parameter to
   glob())?
   - Currently, asan's replace_str flag does not apply to string routines
   already in the common set (AFAICT).  Presumably this is not intentional.
   - Are you ok with adding interceptors to a sanitizer that were not there
   before: e.g., putting strchr into the common set will add it to msan (it's
   already in asan and tsan). Is there additional testing that must be done in
   such cases beyond the llvm tests?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160304/825134fa/attachment.html>