[PATCH] Fix tests for new str interceptors

Evgeniy Stepanov eugenis at google.com
Tue Jun 9 14:09:08 PDT 2015


OI would be great if someone investigated the "s3" point in my other comment, but this change alone should make the tests much more stable, so LGTM.


================
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);
----------------
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.

http://reviews.llvm.org/D10336

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






More information about the llvm-commits mailing list