[PATCH] Documentation for sanitizer special case list

Alexey Samsonov samsonov at google.com
Tue Aug 6 08:52:50 PDT 2013



================
Comment at: docs/SanitizerSpecialCaseList.rst:62
@@ +61,3 @@
+    # Turn off checks for the source file (use absolute path or path relative
+    # to the current working directory):
+    src:/path/to/source/file.c
----------------
Sean Silva wrote:
> The compiler's working directory? Or the file's working directory?
I don't understand this. "cwd" is "the directory, from which user invoked a compiler" (see the example). How to formulate this better?

================
Comment at: docs/SanitizerSpecialCaseList.rst:67-68
@@ +66,4 @@
+    fun:_Z8MyFooBarv
+    # Basic regular expressions are supported:
+    fun:bad_(foo|bar)
+    src:bad_source[1-9].c
----------------
Sean Silva wrote:
> I believe that parenthesized alternations like this are actually extended RE syntax an not supported by basic RE's.
> 
> ```
> $ echo "foo\nbar" | grep '(foo|bar)'
> $ echo "foo\nbar" | grep -E '(foo|bar)'
> foo
> bar
> ```
Ah, right, ERE are supported. Fixed this.

================
Comment at: docs/SanitizerSpecialCaseList.rst:54
@@ +53,3 @@
+
+Each line contains a prefix, followed by a colon and a regular expression.
+Empty lines and lines starting with "#" are ignored. Prefix defines the type
----------------
Sean Silva wrote:
> What about the `=foo` at the end?
> 
> Also, you can't just say "regular expression" when the meaning of `*` is different (and a tiny note in the comment below not sufficient). Please say something like "regular expression except that `*` is used as in shell wildcarding", or something like that.
Rewritten this paragraph and added a category example.

================
Comment at: docs/ThreadSanitizer.rst:100-104
@@ -99,1 +99,7 @@
 
+Blacklist
+---------
+
+You may use :doc:`SanitizerSpecialCaseList` to disable ThreadSanitizer checks
+for certain functions and source files. Data race reports will be suppressed.
+
----------------
Sean Silva wrote:
> I would prefer if this were made more precise, saying something like "ThreadSanitizer supports the `src:` and `fun:` prefixes in :doc:`SanitizerSpecialCaseList`, which will suppress data race reports in the specified files/functions."
Done

================
Comment at: docs/AddressSanitizer.rst:132-135
@@ +131,6 @@
+
+You may use sanitizer special case list to disable AddressSanizier checks for
+certain source files, functions and global variables. See
+:doc:`SanitizerSpecialCaseList` for general file format description.
+AddressSanitizer-specific entry formats are:
+
----------------
Sean Silva wrote:
> You need to actually describe each entry type. Examples are nice, but this is meant to be reference documentation so it has to serve that purpose as well. You probably want to explicitly list the supported prefixes and suffixes, describe each of their meanings, and provide examples for each one.
> 
> You may want to centralize the description of `src:` and `fun:` to `SanitizerSpecialCaseList.rst`
Added more details here.

================
Comment at: docs/AddressSanitizer.rst:144
@@ +143,3 @@
+    global:bad_init_global=init
+    type:*Namespace::BadInitClassName*=init
+    src:bad/init/files/*=init
----------------
Sean Silva wrote:
> It's not at all clear what this line is meant to match. Does it match all initializers of a specific type? How is the wildcarding performed (would the entry `type:std::*=init` match all types in namespace `std` and all nested namespaces? What about inline namespaces? Does it demangle the symbol name to get this?
Oh yes, the format for types is not user-friendly at all. I tried to briefly describe it anyway.


http://llvm-reviews.chandlerc.com/D1268



More information about the cfe-commits mailing list