[PATCH] Fix tests for new str interceptors

[Evgeniy Stepanov]

================
Comment at: test/asan/TestCases/strcasestr-1.c:21
@@ -20,2 +20,3 @@
   r = strcasestr(s1, s2);
   // CHECK:'s{{[1|3]}}' <== Memory access at offset {{[0-9]+ .*}}flows this variable
+  assert(r == s1 + 1);
----------------
ygribov wrote:
> eugenis wrote:
> > I missed the original code review, but this "s3" business looks highly suspicious. Firstly, it is not good to rely on the order of variable declarations in the function body, compiler definitely does not promise anything about that. Secondly, if ASan may say that access overflows s3 - I'd treat this as a bug in the tool. Why does it happen? COMMON_INTERCEPTOR_READ_* should point to the first poisoned byte in the memory range, which should be the first byte after the end of s1.
> > 
> I think we do need to put stopping zero byte somehow to ensure that e.g. underlying Glibc's strcasestr always terminates. Any suggestions how to achieve this in a cleaner way? Perhaps set last byte of s1's redzone to 0 in a noinline no_sanitize_address helper function?
> 
> Overflow in s3 is strange indeed.
Maybe just allocate a larger buffer for the string and __asan_poison part of it. The report would just say "wild address" though, without a reference to s1/s2 variables.

http://reviews.llvm.org/D10336

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/