annotations.html revision 1e4162fb02058324d4866763f1be8d69a54f3b7c
1<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" 2 "http://www.w3.org/TR/html4/strict.dtd"> 3<html> 4<head> 5 <title>Source Annotations</title> 6 <link type="text/css" rel="stylesheet" href="menu.css" /> 7 <link type="text/css" rel="stylesheet" href="content.css" /> 8 <script type="text/javascript" src="scripts/menu.js"></script> 9</head> 10<body> 11 12<div id="page"> 13<!--#include virtual="menu.html.incl"--> 14 15<div id="content"> 16 17<h1>Source Annotations</h1> 18 19<p>The Clang frontend supports several source-level annotations in the form of 20<a href="http://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html">GCC-style 21attributes</a> and pragmas that can help make using the Clang Static Analyzer 22more useful. These annotations can both help suppress false positives as well as 23enhance the analyzer's ability to find bugs.</p> 24 25<p>This page gives a practical overview of such annotations. For more technical 26specifics regarding Clang-specific annotations please see the Clang's list of <a 27href="http://clang.llvm.org/docs/LanguageExtensions.html">language 28extensions</a>. Details of "standard" GCC attributes (that Clang also 29supports) can be found in the <a href="http://gcc.gnu.org/onlinedocs/gcc/">GCC 30manual</a>, with the majority of the relevant attributes being in the section on 31<a href="http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html">function 32attributes</a>.</p> 33 34<p>Note that attributes that are labeled <b>Clang-specific</b> are not 35recognized by GCC. Their use can be conditioned using preprocessor macros 36(examples included on this page).</p> 37 38<h4>Specific Topics</h4> 39 40<ul> 41<li><a href="#generic">Annotations to Enhance Generic Checks</a> 42 <ul> 43 <li><a href="#null_checking"><span>Null Pointer Checking</span></a> 44 <ul> 45 <li><a href="#attr_nonnull"><span>Attribute 'nonnull'</span></a></li> 46 </ul> 47 </li> 48 </ul> 49</li> 50<li><a href="#macosx">Mac OS X API Annotations</a> 51 <ul> 52 <li><a href="#cocoa_mem">Cocoa & Core Foundation Memory Management Annotations</a> 53 <ul> 54 <li><a href="#attr_ns_returns_retained">Attribute 'ns_returns_retained'</a></li> 55 <li><a href="#attr_ns_returns_not_retained">Attribute 'ns_returns_not_retained'</a></li> 56 <li><a href="#attr_cf_returns_retained">Attribute 'cf_returns_retained'</a></li> 57 <li><a href="#attr_cf_returns_not_retained">Attribute 'cf_returns_not_retained'</a></li> 58 <li><a href="#attr_ns_consumed">Attribute 'ns_consumed'</a></li> 59 <li><a href="#attr_cf_consumed">Attribute 'cf_consumed'</a></li> 60 <li><a href="#attr_ns_consumes_self">Attribute 'ns_consumes_self'</a></li> 61 </ul> 62 </li> 63 </ul> 64</li> 65<li><a href="#custom_assertions">Custom Assertion Handlers</a> 66 <ul> 67 <li><a href="#attr_noreturn">Attribute 'noreturn'</a></li> 68 <li><a href="#attr_analyzer_noreturn">Attribute 'analyzer_noreturn'</a></li> 69 </ul> 70 </li> 71</ul> 72 73<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> 74<h2 id="generic">Annotations to Enhance Generic Checks</h2> 75<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> 76 77<h3 id="null_checking">Null Pointer Checking</h3> 78 79<h4 id="attr_nonnull">Attribute 'nonnull'</h4> 80 81<p>The analyzer recognizes the GCC attribute 'nonnull', which indicates that a 82function expects that a given function parameter is not a null pointer. Specific 83details of the syntax of using the 'nonnull' attribute can be found in <a 84href="http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#index-g_t_0040code_007bnonnull_007d-function-attribute-2263">GCC's 85documentation</a>.</p> 86 87<p>Both the Clang compiler and GCC will flag warnings for simple cases where a 88null pointer is directly being passed to a function with a 'nonnull' parameter 89(e.g., as a constant). The analyzer extends this checking by using its deeper 90symbolic analysis to track what pointer values are potentially null and then 91flag warnings when they are passed in a function call via a 'nonnull' 92parameter.</p> 93 94<p><b>Example</b></p> 95 96<pre class="code_example"> 97<span class="command">$ cat test.m</span> 98int bar(int*p, int q, int *r) __attribute__((nonnull(1,3))); 99 100int foo(int *p, int *q) { 101 return !p ? bar(q, 2, p) 102 : bar(p, 2, q); 103} 104</pre> 105 106<p>Running <tt>scan-build</tt> over this source produces the following 107output:</p> 108 109<img src="images/example_attribute_nonnull.png"> 110 111<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> 112<h2 id="macosx">Mac OS X API Annotations</h2> 113<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> 114 115<h3 id="cocoa_mem">Cocoa & Core Foundation Memory Management 116Annotations</h3> 117 118<!-- 119<p>As described in <a href="/available_checks.html#retain_release">Available 120Checks</a>, 121--> 122<p>The analyzer supports the proper management of retain counts for 123both Cocoa and Core Foundation objects. This checking is largely based on 124enforcing Cocoa and Core Foundation naming conventions for Objective-C methods 125(Cocoa) and C functions (Core Foundation). Not strictly following these 126conventions can cause the analyzer to miss bugs or flag false positives.</p> 127 128<p>One can educate the analyzer (and others who read your code) about methods or 129functions that deviate from the Cocoa and Core Foundation conventions using the 130attributes described here.</p> 131 132<h4 id="attr_ns_returns_retained">Attribute 'ns_returns_retained' 133(Clang-specific)</h4> 134 135<p>The GCC-style (Clang-specific) attribute 'ns_returns_retained' allows one to 136annotate an Objective-C method or C function as returning a retained Cocoa 137object that the caller is responsible for releasing (via sending a 138<tt>release</tt> message to the object).</p> 139 140<p><b>Placing on Objective-C methods</b>: For Objective-C methods, this 141annotation essentially tells the analyzer to treat the method as if its name 142begins with "alloc" or "new" or contais the word 143"copy".</p> 144 145<p><b>Placing on C functions</b>: For C functions returning Cocoa objects, the 146analyzer typically does not make any assumptions about whether or not the object 147is returned retained. Explicitly adding the 'ns_returns_retained' attribute to C 148functions allows the analyzer to perform extra checking.</p> 149 150<p><b>Important note when using Garbage Collection</b>: Note that the analyzer 151interprets this attribute slightly differently when using Objective-C garbage 152collection (available on Mac OS 10.5+). When analyzing Cocoa code that uses 153garbage collection, "alloc" methods are assumed to return an object 154that is managed by the garbage collector (and thus doesn't have a retain count 155the caller must balance). These same assumptions are applied to methods or 156functions annotated with 'ns_returns_retained'. If you are returning a Core 157Foundation object (which may not be managed by the garbage collector) you should 158use 'cf_returns_retained'.</p> 159 160<p><b>Example</b></p> 161 162<pre class="code_example"> 163<span class="command">$ cat test.m</span> 164#import <Foundation/Foundation.h> 165 166#ifndef __has_feature // Optional. 167#define __has_feature(x) 0 // Compatibility with non-clang compilers. 168#endif 169 170#ifndef NS_RETURNS_RETAINED 171#if __has_feature(attribute_ns_returns_retained) 172<span class="code_highlight">#define NS_RETURNS_RETAINED __attribute__((ns_returns_retained))</span> 173#else 174#define NS_RETURNS_RETAINED 175#endif 176#endif 177 178@interface MyClass : NSObject {} 179- (NSString*) returnsRetained <span class="code_highlight">NS_RETURNS_RETAINED</span>; 180- (NSString*) alsoReturnsRetained; 181@end 182 183@implementation MyClass 184- (NSString*) returnsRetained { 185 return [[NSString alloc] initWithCString:"no leak here"]; 186} 187- (NSString*) alsoReturnsRetained { 188 return [[NSString alloc] initWithCString:"flag a leak"]; 189} 190@end 191</pre> 192 193<p>Running <tt>scan-build</tt> on this source file produces the following output:</p> 194 195<img src="images/example_ns_returns_retained.png"> 196 197<h4 id="attr_ns_returns_not_retained">Attribute 'ns_returns_not_retained' 198(Clang-specific)</h4> 199 200<p>The 'ns_returns_not_retained' attribute is the complement of '<a 201href="#attr_ns_returns_retained">ns_returns_retained</a>'. Where a function or 202method may appear to obey the Cocoa conventions and return a retained Cocoa 203object, this attribute can be used to indicate that the object reference 204returned should not be considered as an "owning" reference being 205returned to the caller.</p> 206 207<p>Usage is identical to <a 208href="#attr_ns_returns_retained">ns_returns_retained</a>. When using the 209attribute, be sure to declare it within the proper macro that checks for 210its availability, as it is not available in earlier versions of the analyzer:</p> 211 212<pre class="code_example"> 213<span class="command">$ cat test.m</span> 214#ifndef __has_feature // Optional. 215#define __has_feature(x) 0 // Compatibility with non-clang compilers. 216#endif 217 218#ifndef NS_RETURNS_NOT_RETAINED 219#if __has_feature(attribute_ns_returns_not_retained) 220<span class="code_highlight">#define NS_RETURNS_NOT_RETAINED __attribute__((ns_returns_not_retained))</span> 221#else 222#define NS_RETURNS_NOT_RETAINED 223#endif 224#endif 225</pre> 226 227<h4 id="attr_cf_returns_retained">Attribute 'cf_returns_retained' 228(Clang-specific)</h4> 229 230<p>The GCC-style (Clang-specific) attribute 'cf_returns_retained' allows one to 231annotate an Objective-C method or C function as returning a retained Core 232Foundation object that the caller is responsible for releasing. 233 234<p><b>Placing on Objective-C methods</b>: With respect to Objective-C methods., 235this attribute is identical in its behavior and usage to 'ns_returns_retained' 236except for the distinction of returning a Core Foundation object instead of a 237Cocoa object. This distinction is important for two reasons:</p> 238 239<ul> 240 <li>Core Foundation objects are not automatically managed by the Objective-C 241 garbage collector.</li> 242 <li>Because Core Foundation is a C API, the analyzer cannot always tell that a 243 pointer return value refers to a Core Foundation object. In contrast, it is 244 trivial for the analyzer to recognize if a pointer refers to a Cocoa object 245 (given the Objective-C type system).</p> 246</ul> 247 248<p><b>Placing on C functions</b>: When placing the attribute 249'cf_returns_retained' on the declarations of C functions, the analyzer 250interprets the function as:</p> 251 252<ol> 253 <li>Returning a Core Foundation Object</li> 254 <li>Treating the function as if it its name 255contained the keywords "create" or "copy". This means the 256returned object as a +1 retain count that must be released by the caller, either 257by sending a <tt>release</tt> message (via toll-free bridging to an Objective-C 258object pointer), calling <tt>CFRelease</tt> (or similar function), or using 259<tt>CFMakeCollectable</tt> to register the object with the Objective-C garbage 260collector.</li> 261</ol> 262 263<p><b>Example</b></p> 264 265<p>In this example, observe the difference in output when the code is compiled 266to not use garbage collection versus when it is compiled to only use garbage 267collection (<tt>-fobjc-gc-only</tt>).</p> 268 269<pre class="code_example"> 270<span class="command">$ cat test.m</span> 271$ cat test.m 272#import <Cocoa/Cocoa.h> 273 274#ifndef __has_feature // Optional. 275#define __has_feature(x) 0 // Compatibility with non-clang compilers. 276#endif 277 278#ifndef CF_RETURNS_RETAINED 279#if __has_feature(attribute_cf_returns_retained) 280<span class="code_highlight">#define CF_RETURNS_RETAINED __attribute__((cf_returns_retained))</span> 281#else 282#define CF_RETURNS_RETAINED 283#endif 284#endif 285 286@interface MyClass : NSObject {} 287- (NSDate*) returnsCFRetained <span class="code_highlight">CF_RETURNS_RETAINED</span>; 288- (NSDate*) alsoReturnsRetained; 289- (NSDate*) returnsNSRetained <span class="code_highlight">NS_RETURNS_RETAINED</span>; 290@end 291 292<span class="code_highlight">CF_RETURNS_RETAINED</span> 293CFDateRef returnsRetainedCFDate() { 294 return CFDateCreate(0, CFAbsoluteTimeGetCurrent()); 295} 296 297@implementation MyClass 298- (NSDate*) returnsCFRetained { 299 return (NSDate*) returnsRetainedCFDate(); <b><i>// No leak.</i></b> 300} 301 302- (NSDate*) alsoReturnsRetained { 303 return (NSDate*) returnsRetainedCFDate(); <b><i>// Always report a leak.</i></b> 304} 305 306- (NSDate*) returnsNSRetained { 307 return (NSDate*) returnsRetainedCFDate(); <b><i>// Report a leak when using GC.</i></b> 308} 309@end 310</pre> 311 312<p>Running <tt>scan-build</tt> on this example produces the following output:</p> 313 314<img src="images/example_cf_returns_retained.png"> 315 316</p>When the above code is compiled using Objective-C garbage collection (i.e., 317code is compiled with the flag <tt>-fobjc-gc</tt> or <tt>-fobjc-gc-only</tt>), 318<tt>scan-build</tt> produces both the above error (with slightly different text 319to indicate the code uses garbage collection) as well as the following warning, 320which indicates a leak that occurs <em>only</em> when using garbage 321collection:</p> 322 323<img src="images/example_cf_returns_retained_gc.png"> 324 325<h4 id="attr_cf_returns_not_retained">Attribute 'cf_returns_not_retained' 326(Clang-specific)</h4> 327 328<p>The 'cf_returns_not_retained' attribute is the complement of '<a 329href="#attr_cf_returns_retained">cf_returns_retained</a>'. Where a function or 330method may appear to obey the Core Foundation or Cocoa conventions and return 331a retained Core Foundation object, this attribute can be used to indicate that 332the object reference returned should not be considered as an 333"owning" reference being returned to the caller.</p> 334 335<p>Usage is identical to <a 336href="#attr_cf_returns_retained">cf_returns_retained</a>. When using the 337attribute, be sure to declare it within the proper macro that checks for 338its availability, as it is not available in earlier versions of the analyzer:</p> 339 340<pre class="code_example"> 341<span class="command">$ cat test.m</span> 342#ifndef __has_feature // Optional. 343#define __has_feature(x) 0 // Compatibility with non-clang compilers. 344#endif 345 346#ifndef CF_RETURNS_NOT_RETAINED 347#if __has_feature(attribute_cf_returns_not_retained) 348<span class="code_highlight">#define CF_RETURNS_NOT_RETAINED __attribute__((cf_returns_not_retained))</span> 349#else 350#define CF_RETURNS_NOT_RETAINED 351#endif 352#endif 353</pre> 354 355<h4 id="attr_ns_consumed">Attribute 'ns_consumed' 356(Clang-specific)</h4> 357 358<p>The 'ns_consumed' attribute can be placed on a specific parameter in either the declaration of a function or an Objective-C method. 359 It indicates to the static analyzer that a <tt>release</tt> message is implicitly sent to the parameter upon 360 completion of the call to the given function or method. 361 362<p><b>Important note when using Garbage Collection</b>: Note that the analyzer 363essentially ignores this attribute when code is compiled to use Objective-C 364garbage collection. This is because the <tt>release</tt> message does nothing 365when using GC. If the underlying function/method uses something like 366<tt>CFRelease</tt> to decrement the reference count, consider using 367the <a href="#attr_cf_consumed">cf_consumed</a> attribute instead.</p> 368 369<p><b>Example</b></p> 370 371<pre class="code_example"> 372<span class="command">$ cat test.m</span> 373#ifndef __has_feature // Optional. 374#define __has_feature(x) 0 // Compatibility with non-clang compilers. 375#endif 376 377#ifndef NS_CONSUMED 378#if __has_feature(attribute_ns_consumed) 379<span class="code_highlight">#define NS_CONSUMED __attribute__((ns_consumed))</span> 380#else 381#define NS_CONSUMED 382#endif 383#endif 384 385void consume_ns(id <span class="code_highlight">NS_CONSUMED</span> x); 386 387void test() { 388 id x = [[NSObject alloc] init]; 389 consume_ns(x); <b><i>// No leak!</i></b> 390} 391 392@interface Foo : NSObject 393+ (void) releaseArg:(id) <span class="code_highlight">NS_CONSUMED</span> x; 394+ (void) releaseSecondArg:(id)x second:(id) <span class="code_highlight">NS_CONSUMED</span> y; 395@end 396 397void test_method() { 398 id x = [[NSObject alloc] init]; 399 [Foo releaseArg:x]; <b><i>// No leak!</i></b> 400} 401 402void test_method2() { 403 id a = [[NSObject alloc] init]; 404 id b = [[NSObject alloc] init]; 405 [Foo releaseSecondArg:a second:b]; <b><i>// 'a' is leaked, but 'b' is released.</i></b> 406} 407</pre> 408 409<h4 id="attr_cf_consumed">Attribute 'cf_consumed' 410(Clang-specific)</h4> 411 412<p>The 'cf_consumed' attribute is practically identical to <a href="#attr_ns_consumed">ns_consumed</a>. 413The attribute can be placed on a specific parameter in either the declaration of a function or an Objective-C method. 414It indicates to the static analyzer that the object reference is implicitly passed to a call to <tt>CFRelease</tt> upon 415completion of the call to the given function or method.</p> 416 417<p>Operationally this attribute is nearly identical to ns_consumed 418with the main difference that the reference count decrement still occurs when using Objective-C garbage 419collection (which is import for Core Foundation types, which are not automatically garbage collected).</p> 420 421<p><b>Example</b></p> 422 423<pre class="code_example"> 424<span class="command">$ cat test.m</span> 425#ifndef __has_feature // Optional. 426#define __has_feature(x) 0 // Compatibility with non-clang compilers. 427#endif 428 429#ifndef CF_CONSUMED 430#if __has_feature(attribute_cf_consumed) 431<span class="code_highlight">#define CF_CONSUMED __attribute__((cf_consumed))</span> 432#else 433#define CF_CONSUMED 434#endif 435#endif 436 437void consume_cf(id <span class="code_highlight">CF_CONSUMED</span> x); 438void consume_CFDate(CFDateRef <span class="code_highlight">CF_CONSUMED</span> x); 439 440void test() { 441 id x = [[NSObject alloc] init]; 442 consume_cf(x); <b><i>// No leak!</i></b> 443} 444 445void test2() { 446 CFDateRef date = CFDateCreate(0, CFAbsoluteTimeGetCurrent()); 447 consume_CFDate(date); <b><i>// No leak, including under GC!</i></b> 448 449} 450 451@interface Foo : NSObject 452+ (void) releaseArg:(CFDateRef) <span class="code_highlight">CF_CONSUMED</span> x; 453@end 454 455void test_method() { 456 CFDateRef date = CFDateCreate(0, CFAbsoluteTimeGetCurrent()); 457 [Foo releaseArg:date]; <b><i>// No leak!</i></b> 458} 459</pre> 460 461<h4 id="attr_ns_consumes_self">Attribute 'ns_consumes_self' 462(Clang-specific)</h4> 463 464<p>The 'ns_consumes_self' attribute can be placed only on an Objective-C method declaration. 465 It indicates that the receiver of the message is "consumed" (a single reference count decremented) 466 after the message is sent. This matches the semantics of all "init" methods. 467</p> 468 469<p>One use of this attribute is declare your own init-like methods that do not follow the 470 standard Cocoa naming conventions.</p> 471 472<p><b>Example</b></p> 473 474<pre class="code_example"> 475#ifndef __has_feature 476#define __has_feature(x) 0 // Compatibility with non-clang compilers. 477#endif 478 479#ifndef NS_CONSUMES_SELF 480#if __has_feature((attribute_ns_consumes_self)) 481<span class="code_highlight">#define NS_CONSUMES_SELF __attribute__((ns_consumes_self))</span> 482#else 483#define NS_CONSUMES_SELF 484#endif 485#endif 486 487@interface MyClass : NSObject 488- initWith:(MyClass *)x; 489- nonstandardInitWith:(MyClass *)x <span class="code_highlight">NS_CONSUMES_SELF</span> NS_RETURNS_RETAINED; 490@end 491</pre> 492 493<p>In this example, <tt>nonstandardInitWith:</tt> has the same ownership semantics as the init method <tt>initWith:</tt>. 494 The static analyzer will observe that the method consumes the receiver, and then returns an object with a +1 retain count.</p> 495 496<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> 497<h2 id="custom_assertions">Custom Assertion Handlers</h2> 498<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> 499 500<p>The analyzer exploits code assertions by pruning off paths where the 501assertion condition is false. The idea is capture any program invariants 502specified in the assertion that the developer may know but is not immediately 503apparent in the code itself. In this way assertions make implicit assumptions 504explicit in the code, which not only makes the analyzer more accurate when 505finding bugs, but can help others better able to understand your code as well. 506It can also help remove certain kinds of analyzer false positives by pruning off 507false paths.</p> 508 509<p>In order to exploit assertions, however, the analyzer must understand when it 510encounters an "assertion handler." Typically assertions are 511implemented with a macro, with the macro performing a check for the assertion 512condition and, when the check fails, calling an assertion handler. For example, consider the following code 513fragment:</p> 514 515<pre class="code_example"> 516void foo(int *p) { 517 assert(p != NULL); 518} 519</pre> 520 521<p>When this code is preprocessed on Mac OS X it expands to the following:</p> 522 523<pre class="code_example"> 524void foo(int *p) { 525 (__builtin_expect(!(p != NULL), 0) ? __assert_rtn(__func__, "t.c", 4, "p != NULL") : (void)0); 526} 527</pre> 528 529<p>In this example, the assertion handler is <tt>__assert_rtn</tt>. When called, 530most assertion handlers typically print an error and terminate the program. The 531analyzer can exploit such semantics by ending the analysis of a path once it 532hits a call to an assertion handler.</p> 533 534<p>The trick, however, is that the analyzer needs to know that a called function 535is an assertion handler; otherwise the analyzer might assume the function call 536returns and it will continue analyzing the path where the assertion condition 537failed. This can lead to false positives, as the assertion condition usually 538implies a safety condition (e.g., a pointer is not null) prior to performing 539some action that depends on that condition (e.g., dereferencing a pointer).</p> 540 541<p>The analyzer knows about several well-known assertion handlers, but can 542automatically infer if a function should be treated as an assertion handler if 543it is annotated with the 'noreturn' attribute or the (Clang-specific) 544'analyzer_noreturn' attribute.</p> 545 546<h4 id="attr_noreturn">Attribute 'noreturn'</h4> 547 548<p>The 'noreturn' attribute is a GCC-attribute that can be placed on the 549declarations of functions. It means exactly what its name implies: a function 550with a 'noreturn' attribute should never return.</p> 551 552<p>Specific details of the syntax of using the 'noreturn' attribute can be found 553in <a 554href="http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#index-g_t_0040code_007bnoreturn_007d-function-attribute-2264">GCC's 555documentation</a>.</p> 556 557<p>Not only does the analyzer exploit this information when pruning false paths, 558but the compiler also takes it seriously and will generate different code (and 559possibly better optimized) under the assumption that the function does not 560return.</p> 561 562<p><b>Example</b></p> 563 564<p>On Mac OS X, the function prototype for <tt>__assert_rtn</tt> (declared in 565<tt>assert.h</tt>) is specifically annotated with the 'noreturn' attribute:</p> 566 567<pre class="code_example"> 568void __assert_rtn(const char *, const char *, int, const char *) <span class="code_highlight">__attribute__((__noreturn__))</span>; 569</pre> 570 571<h4 id="attr_analyzer_noreturn">Attribute 'analyzer_noreturn' (Clang-specific)</h4> 572 573<p>The Clang-specific 'analyzer_noreturn' attribute is almost identical to 574'noreturn' except that it is ignored by the compiler for the purposes of code 575generation.</p> 576 577<p>This attribute is useful for annotating assertion handlers that actually 578<em>can</em> return, but for the purpose of using the analyzer we want to 579pretend that such functions do not return.</p> 580 581<p>Because this attribute is Clang-specific, its use should be conditioned with 582the use of preprocessor macros.</p> 583 584<p><b>Example</b> 585 586<pre class="code_example"> 587#ifndef CLANG_ANALYZER_NORETURN 588#if __has_feature(attribute_analyzer_noreturn) 589<span class="code_highlight">#define CLANG_ANALYZER_NORETURN __attribute__((analyzer_noreturn))</span> 590#else 591#define CLANG_ANALYZER_NORETURN 592#endif 593 594void my_assert_rtn(const char *, const char *, int, const char *) <span class="code_highlight">CLANG_ANALYZER_NORETURN</span>; 595</pre> 596 597</div> 598</div> 599</body> 600</html> 601 602