[PATCH] New "strict_string_checks" run-time flag

Alexander Potapenko glider at google.com
Wed Jan 28 02:09:14 PST 2015


A couple of ideas how we can proceed with the tests:

1. make UnitTests extract |strict_string_checks| from ASAN_OPTIONS and fix the checks to behave based on that setting;
2. remove the failing checks from the test suite and write the corresponding lit tests that will test both strict_string_checks modes (or drop them if they're covered by the tests you've added in this CL);
3. fix the failing checks assuming that strict_string_checks is always on.

I've taken a look at the failing tests and it didn't occur to me that we had ever wanted to "rely" on non-strict semantics.
Those corner cases indeed need to be carefully checked (especially now, when there're two modes of string interceptors operation), but that doesn't mean we have to stick with the non-default behavior.


================
Comment at: test/asan/Unit/lit.site.cfg.in:33
@@ +32,2 @@
+# Disable strict str checks in unit tests
+config.environment['ASAN_OPTIONS'] = 'strict_string_checks=false'
----------------
ygribov wrote:
> kcc wrote:
> > Hm. Why? 
> Some tests relied on non-strict semantics.
I think we must fix the tests. It's not a good idea to silently change the default string checking mode in a bunch of tests.
The best solution is to make these OOB reports depend on the flag value (can the unit test read common_flags?)

http://reviews.llvm.org/D7123

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






More information about the llvm-commits mailing list