<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 4, 2016 at 11:48 AM, Derek Bruening <span dir="ltr"><<a href="mailto:bruening@google.com" target="_blank">bruening@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Fri, Mar 4, 2016 at 2:34 PM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span>On Fri, Mar 4, 2016 at 11:32 AM, Derek Bruening <span dir="ltr"><<a href="mailto:bruening@google.com" target="_blank">bruening@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">bruening added a comment.<br>
<br>
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.<br></blockquote></span><div>In most cases such unification is more than welcome! </div><div>(Just need to be careful not to lose any functionality) </div></div></div></div></blockquote><div><br></div></span><div>Putting more into the common set will make it easier to add new tools as well.</div><div><br></div><div>Perhaps you could give your thoughts on some of the complexities involved:</div><div><ul><li>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())?</li></ul></div></div></div></div></blockquote><div>Not really. Let's leave replace_str as as and add new flags for other (classes of) interceptors if needed. </div><div>This flags are unfortunate, but required -- different users have different sets of bugs they can not fix. :( </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><ul><li>Currently, asan's replace_str flag does not apply to string routines already in the common set (AFAICT).  Presumably this is not intentional.</li></ul></div></div></div></div></blockquote><div>semi-intentional. :) </div><div>replace_str was a mistake, we really needed a separate flag for every interceptor (or at least a class if related interceptors, like *printf*) </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><ul><li>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?</li></ul></div></div></div></div></blockquote><div>More than OK, it's welcome! </div><div>As long as every new interceptor is under it's own flag (or a class of related new interceptors under a single flag) </div><div>it's ok even if the flag is on by default (preferred). </div></div>If such a new interceptor cases a new failure we will be able to disable it quickly (while not disabling the old interceptors). </div></div>