Skip to content

Commit b9207ae

Browse files
authored
[NFC][analyzer][docs] Improve Annotations.rst (llvm#122749)
This commit fixes three issues within the documentation file `Annotations.rst` which was recently created by my earlier commit llvm#122246 . (1) The section title "Annotations to Enhance Generic Checks" is changed to "General Purpose Annotations" because it was a bit too verbose and it used the obsolete name "checks" for what we now call "checkers" in the static analyzer. (2) Several code blocks were missing from the generated html because I accidentally used `.. code-block: c` instead of `.. code-block:: c` and so Sphinx parsed them as comment blocks. (Without printing any error or warning...) (3) The `ownership_*` attributes (which are used by `MallocChecker`) were missing from this document, so I wrote a section that briefly describes them and links to their full documentation.
1 parent 65136a3 commit b9207ae

File tree

1 file changed

+44
-8
lines changed

1 file changed

+44
-8
lines changed

clang/docs/analyzer/user-docs/Annotations.rst

+44-8
Original file line numberDiff line numberDiff line change
@@ -23,8 +23,8 @@ recognized by GCC. Their use can be conditioned using preprocessor macros
2323
.. contents::
2424
:local:
2525

26-
Annotations to Enhance Generic Checks
27-
_____________________________________
26+
General Purpose Annotations
27+
___________________________
2828

2929
Null Pointer Checking
3030
#####################
@@ -79,15 +79,15 @@ implemented with a macro, with the macro performing a check for the assertion
7979
condition and, when the check fails, calling an assertion handler. For
8080
example, consider the following code fragment:
8181

82-
.. code-block: c
82+
.. code-block:: c
8383
8484
void foo(int *p) {
8585
assert(p != NULL);
8686
}
8787
8888
When this code is preprocessed on Mac OS X it expands to the following:
8989

90-
.. code-block: c
90+
.. code-block:: c
9191
9292
void foo(int *p) {
9393
(__builtin_expect(!(p != NULL), 0) ? __assert_rtn(__func__, "t.c", 4, "p != NULL") : (void)0);
@@ -131,7 +131,7 @@ return.
131131
On Mac OS X, the function prototype for ``__assert_rtn`` (declared in
132132
``assert.h``) is specifically annotated with the 'noreturn' attribute:
133133

134-
.. code-block: c
134+
.. code-block:: c
135135
136136
void __assert_rtn(const char *, const char *, int, const char *) __attribute__((__noreturn__));
137137
@@ -151,7 +151,7 @@ the use of preprocessor macros.
151151

152152
**Example**
153153

154-
.. code-block: c
154+
.. code-block:: c
155155
156156
#ifndef CLANG_ANALYZER_NORETURN
157157
#if __has_feature(attribute_analyzer_noreturn)
@@ -163,6 +163,43 @@ the use of preprocessor macros.
163163
164164
void my_assert_rtn(const char *, const char *, int, const char *) CLANG_ANALYZER_NORETURN;
165165
166+
Dynamic Memory Modeling Annotations
167+
###################################
168+
169+
If a project uses custom functions for dynamic memory management (that e.g. act as wrappers around ``malloc``/``free`` or ``new``/``delete`` in C++) and the analyzer cannot "see" the _definitions_ of these functions, it's possible to annotate their declarations to let the analyzer model their behavior. (Otherwise the analyzer cannot know that the opaque ``my_free()`` is basically equivalent to a standard ``free()`` call.)
170+
171+
.. note::
172+
**This page only provides a brief list of these annotations.** For a full documentation, see the main `Attributes in Clang <../../AttributeReference.html#ownership-holds-ownership-returns-ownership-takes-clang-static-analyzer>`_ page.
173+
174+
Attribute 'ownership_returns' (Clang-specific)
175+
----------------------------------------------
176+
177+
Use this attribute to mark functions that return dynamically allocated memory. Takes a single argument, the type of the allocation (e.g. ``malloc`` or ``new``).
178+
179+
.. code-block:: c
180+
181+
void __attribute((ownership_returns(malloc))) *my_malloc(size_t);
182+
183+
Attribute 'ownership_takes' (Clang-specific)
184+
--------------------------------------------
185+
186+
Use this attribute to mark functions that deallocate memory. Takes two arguments: the type of the allocation (e.g. ``malloc`` or ``new``) and the index of the parameter that is being deallocated (counting from 1).
187+
188+
.. code-block:: c
189+
190+
void __attribute((ownership_takes(malloc, 1))) my_free(void *);
191+
192+
Attribute 'ownership_holds' (Clang-specific)
193+
--------------------------------------------
194+
195+
Use this attribute to mark functions that take ownership of memory and will deallocate it at some unspecified point in the future. Takes two arguments: the type of the allocation (e.g. ``malloc`` or ``new``) and the index of the parameter that is being held (counting from 1).
196+
197+
.. code-block:: c
198+
199+
void __attribute((ownership_holds(malloc, 2))) store_in_table(int key, record_t *val);
200+
201+
The annotations ``ownership_takes`` and ``ownership_holds`` both prevent memory leak reports (concerning the specified argument); the difference between them is that using taken memory is a use-after-free error, while using held memory is assumed to be legitimate.
202+
166203
Mac OS X API Annotations
167204
________________________
168205

@@ -207,7 +244,7 @@ functions allows the analyzer to perform extra checking.
207244

208245
**Example**
209246

210-
.. code-block: objc
247+
.. code-block:: objc
211248
212249
#import <Foundation/Foundation.h>;
213250
@@ -597,7 +634,6 @@ returned object.
597634
LIBKERN_RETURNS_NOT_RETAINED OSObject *myFieldGetter();
598635
}
599636
600-
601637
// Note that the annotation only has to be applied to the function declaration.
602638
OSObject * MyClass::myFieldGetter() {
603639
return f;

0 commit comments

Comments
 (0)