[PATCH] [asan] Update the llvm webpage describing ASan

Anna Zaks zaks.anna at gmail.com
Mon Jun 22 11:00:48 PDT 2015

Comment at: docs/AddressSanitizer.rst:69
@@ +68,3 @@
+* Fixing bugs becomes unavoidable. AddressSaniftizer does not produce
+  false alarms. Once a memory corruption occurs, the program is in an inconstant
+  state, which could lead to confusing results and potentially misleading
glider wrote:
> samsonov wrote:
> > s/inconstant/inconsistent?
> > 
> "the program heap" instead of "the program", maybe?
It does not have to be the heap; it can be anything. All you know is that something is trying to access an address that is not accessible.

Comment at: docs/AddressSanitizer.rst:78
@@ +77,3 @@
+re-exec.) Also keep in mind that when moving the executable to another machine,
+the asan library will also need to be copied over.
glider wrote:
> "the ASan library"
I am going to correct the capitalization and add the following:
(You can find the library by searching for dynamic libraries with "asan" in their name.)

Comment at: docs/AddressSanitizer.rst:129
@@ +128,3 @@
+AddressSanitizer can optionally detect dynamic initialization order problems,
+when initialization of globals defined in one translation unit uses
glider wrote:
> IIRC this feature still doesn't work on OSX, shall we mention that?
What about Android and FreeBSD?

Comment at: docs/AddressSanitizer.rst:192
@@ -124,3 +191,3 @@
+Disabling Instrumentation with ``__attribute__((no_sanitize_address))``
glider wrote:
> What about `__attribute__((no_sanitize("address")))`?
Should we suggest using __attribute__((no_sanitize("address"))) instead of __attribute__((no_sanitize_address))?

And not mention __attribute__((no_sanitize_address)) at all?



More information about the llvm-commits mailing list