From 222e2a7620e6520ffaf4fc4e69d79c18da31542e Mon Sep 17 00:00:00 2001 From: "Zancanaro; Carlo" Date: Mon, 24 Sep 2012 09:58:17 +1000 Subject: Add the clang library to the repo (with some of my changes, too). --- clang/www/analyzer/annotations.html | 602 +++++++++++++++++++++ clang/www/analyzer/available_checks.html | 147 +++++ clang/www/analyzer/checker_dev_manual.html | 346 ++++++++++++ clang/www/analyzer/content.css | 79 +++ clang/www/analyzer/dev_cxx.html | 54 ++ clang/www/analyzer/filing_bugs.html | 62 +++ clang/www/analyzer/images/analyzer_html.png | Bin 0 -> 63091 bytes clang/www/analyzer/images/analyzer_xcode.png | Bin 0 -> 87697 bytes .../analyzer/images/example_attribute_nonnull.png | Bin 0 -> 25028 bytes .../images/example_cf_returns_retained.png | Bin 0 -> 43528 bytes .../images/example_cf_returns_retained_gc.png | Bin 0 -> 46925 bytes .../images/example_ns_returns_retained.png | Bin 0 -> 40406 bytes clang/www/analyzer/images/scan_build_cmd.png | Bin 0 -> 29669 bytes clang/www/analyzer/images/tree/bullet.gif | Bin 0 -> 64 bytes clang/www/analyzer/images/tree/minus.gif | Bin 0 -> 79 bytes clang/www/analyzer/images/tree/plus.gif | Bin 0 -> 83 bytes clang/www/analyzer/index.html | 224 ++++++++ clang/www/analyzer/installation.html | 114 ++++ clang/www/analyzer/latest_checker.html.incl | 1 + clang/www/analyzer/menu.css | 52 ++ clang/www/analyzer/menu.html.incl | 41 ++ clang/www/analyzer/release_notes.html | 188 +++++++ clang/www/analyzer/scan-build.html | 344 ++++++++++++ clang/www/analyzer/scripts/dbtree.js | 1 + clang/www/analyzer/scripts/menu.js | 17 + clang/www/analyzer/xcode.html | 143 +++++ 26 files changed, 2415 insertions(+) create mode 100644 clang/www/analyzer/annotations.html create mode 100644 clang/www/analyzer/available_checks.html create mode 100644 clang/www/analyzer/checker_dev_manual.html create mode 100644 clang/www/analyzer/content.css create mode 100644 clang/www/analyzer/dev_cxx.html create mode 100644 clang/www/analyzer/filing_bugs.html create mode 100644 clang/www/analyzer/images/analyzer_html.png create mode 100644 clang/www/analyzer/images/analyzer_xcode.png create mode 100644 clang/www/analyzer/images/example_attribute_nonnull.png create mode 100644 clang/www/analyzer/images/example_cf_returns_retained.png create mode 100644 clang/www/analyzer/images/example_cf_returns_retained_gc.png create mode 100644 clang/www/analyzer/images/example_ns_returns_retained.png create mode 100644 clang/www/analyzer/images/scan_build_cmd.png create mode 100644 clang/www/analyzer/images/tree/bullet.gif create mode 100644 clang/www/analyzer/images/tree/minus.gif create mode 100644 clang/www/analyzer/images/tree/plus.gif create mode 100644 clang/www/analyzer/index.html create mode 100644 clang/www/analyzer/installation.html create mode 100644 clang/www/analyzer/latest_checker.html.incl create mode 100644 clang/www/analyzer/menu.css create mode 100644 clang/www/analyzer/menu.html.incl create mode 100644 clang/www/analyzer/release_notes.html create mode 100644 clang/www/analyzer/scan-build.html create mode 100644 clang/www/analyzer/scripts/dbtree.js create mode 100644 clang/www/analyzer/scripts/menu.js create mode 100644 clang/www/analyzer/xcode.html (limited to 'clang/www/analyzer') diff --git a/clang/www/analyzer/annotations.html b/clang/www/analyzer/annotations.html new file mode 100644 index 0000000..9e3583d --- /dev/null +++ b/clang/www/analyzer/annotations.html @@ -0,0 +1,602 @@ + + + + Source Annotations + + + + + + +
+ + +
+ +

Source Annotations

+ +

The Clang frontend supports several source-level annotations in the form of +GCC-style +attributes and pragmas that can help make using the Clang Static Analyzer +more useful. These annotations can both help suppress false positives as well as +enhance the analyzer's ability to find bugs.

+ +

This page gives a practical overview of such annotations. For more technical +specifics regarding Clang-specific annotations please see the Clang's list of language +extensions. Details of "standard" GCC attributes (that Clang also +supports) can be found in the GCC +manual, with the majority of the relevant attributes being in the section on +function +attributes.

+ +

Note that attributes that are labeled Clang-specific are not +recognized by GCC. Their use can be conditioned using preprocessor macros +(examples included on this page).

+ +

Specific Topics

+ + + + +

Annotations to Enhance Generic Checks

+ + +

Null Pointer Checking

+ +

Attribute 'nonnull'

+ +

The analyzer recognizes the GCC attribute 'nonnull', which indicates that a +function expects that a given function parameter is not a null pointer. Specific +details of the syntax of using the 'nonnull' attribute can be found in GCC's +documentation.

+ +

Both the Clang compiler and GCC will flag warnings for simple cases where a +null pointer is directly being passed to a function with a 'nonnull' parameter +(e.g., as a constant). The analyzer extends this checking by using its deeper +symbolic analysis to track what pointer values are potentially null and then +flag warnings when they are passed in a function call via a 'nonnull' +parameter.

+ +

Example

+ +
+$ cat test.m
+int bar(int*p, int q, int *r) __attribute__((nonnull(1,3)));
+
+int foo(int *p, int *q) {
+   return !p ? bar(q, 2, p) 
+             : bar(p, 2, q);
+}
+
+ +

Running scan-build over this source produces the following +output:

+ +example attribute nonnull + + +

Mac OS X API Annotations

+ + +

Cocoa & Core Foundation Memory Management +Annotations

+ + +

The analyzer supports the proper management of retain counts for +both Cocoa and Core Foundation objects. This checking is largely based on +enforcing Cocoa and Core Foundation naming conventions for Objective-C methods +(Cocoa) and C functions (Core Foundation). Not strictly following these +conventions can cause the analyzer to miss bugs or flag false positives.

+ +

One can educate the analyzer (and others who read your code) about methods or +functions that deviate from the Cocoa and Core Foundation conventions using the +attributes described here.

+ +

Attribute 'ns_returns_retained' +(Clang-specific)

+ +

The GCC-style (Clang-specific) attribute 'ns_returns_retained' allows one to +annotate an Objective-C method or C function as returning a retained Cocoa +object that the caller is responsible for releasing (via sending a +release message to the object).

+ +

Placing on Objective-C methods: For Objective-C methods, this +annotation essentially tells the analyzer to treat the method as if its name +begins with "alloc" or "new" or contains the word +"copy".

+ +

Placing on C functions: For C functions returning Cocoa objects, the +analyzer typically does not make any assumptions about whether or not the object +is returned retained. Explicitly adding the 'ns_returns_retained' attribute to C +functions allows the analyzer to perform extra checking.

+ +

Important note when using Garbage Collection: Note that the analyzer +interprets this attribute slightly differently when using Objective-C garbage +collection (available on Mac OS 10.5+). When analyzing Cocoa code that uses +garbage collection, "alloc" methods are assumed to return an object +that is managed by the garbage collector (and thus doesn't have a retain count +the caller must balance). These same assumptions are applied to methods or +functions annotated with 'ns_returns_retained'. If you are returning a Core +Foundation object (which may not be managed by the garbage collector) you should +use 'cf_returns_retained'.

+ +

Example

+ +
+$ cat test.m
+#import <Foundation/Foundation.h>
+
+#ifndef __has_feature      // Optional.
+#define __has_feature(x) 0 // Compatibility with non-clang compilers.
+#endif
+
+#ifndef NS_RETURNS_RETAINED
+#if __has_feature(attribute_ns_returns_retained)
+#define NS_RETURNS_RETAINED __attribute__((ns_returns_retained))
+#else
+#define NS_RETURNS_RETAINED
+#endif
+#endif
+
+@interface MyClass : NSObject {}
+- (NSString*) returnsRetained NS_RETURNS_RETAINED;
+- (NSString*) alsoReturnsRetained;
+@end
+
+@implementation MyClass
+- (NSString*) returnsRetained {
+  return [[NSString alloc] initWithCString:"no leak here"];
+}
+- (NSString*) alsoReturnsRetained {
+  return [[NSString alloc] initWithCString:"flag a leak"];
+}
+@end
+
+ +

Running scan-build on this source file produces the following output:

+ +example returns retained + +

Attribute 'ns_returns_not_retained' +(Clang-specific)

+ +

The 'ns_returns_not_retained' attribute is the complement of 'ns_returns_retained'. Where a function or +method may appear to obey the Cocoa conventions and return a retained Cocoa +object, this attribute can be used to indicate that the object reference +returned should not be considered as an "owning" reference being +returned to the caller.

+ +

Usage is identical to ns_returns_retained. When using the +attribute, be sure to declare it within the proper macro that checks for +its availability, as it is not available in earlier versions of the analyzer:

+ +
+$ cat test.m
+#ifndef __has_feature      // Optional.
+#define __has_feature(x) 0 // Compatibility with non-clang compilers.
+#endif
+
+#ifndef NS_RETURNS_NOT_RETAINED
+#if __has_feature(attribute_ns_returns_not_retained)
+#define NS_RETURNS_NOT_RETAINED __attribute__((ns_returns_not_retained))
+#else
+#define NS_RETURNS_NOT_RETAINED
+#endif
+#endif
+
+ +

Attribute 'cf_returns_retained' +(Clang-specific)

+ +

The GCC-style (Clang-specific) attribute 'cf_returns_retained' allows one to +annotate an Objective-C method or C function as returning a retained Core +Foundation object that the caller is responsible for releasing. + +

Placing on Objective-C methods: With respect to Objective-C methods., +this attribute is identical in its behavior and usage to 'ns_returns_retained' +except for the distinction of returning a Core Foundation object instead of a +Cocoa object. This distinction is important for two reasons:

+ +
    +
  • Core Foundation objects are not automatically managed by the Objective-C + garbage collector.
  • +
  • Because Core Foundation is a C API, the analyzer cannot always tell that a + pointer return value refers to a Core Foundation object. In contrast, it is + trivial for the analyzer to recognize if a pointer refers to a Cocoa object + (given the Objective-C type system). +
+ +

Placing on C functions: When placing the attribute +'cf_returns_retained' on the declarations of C functions, the analyzer +interprets the function as:

+ +
    +
  1. Returning a Core Foundation Object
  2. +
  3. Treating the function as if it its name +contained the keywords "create" or "copy". This means the +returned object as a +1 retain count that must be released by the caller, either +by sending a release message (via toll-free bridging to an Objective-C +object pointer), calling CFRelease (or similar function), or using +CFMakeCollectable to register the object with the Objective-C garbage +collector.
  4. +
+ +

Example

+ +

In this example, observe the difference in output when the code is compiled +to not use garbage collection versus when it is compiled to only use garbage +collection (-fobjc-gc-only).

+ +
+$ cat test.m
+$ cat test.m
+#import <Cocoa/Cocoa.h>
+
+#ifndef __has_feature      // Optional.
+#define __has_feature(x) 0 // Compatibility with non-clang compilers.
+#endif
+
+#ifndef CF_RETURNS_RETAINED
+#if __has_feature(attribute_cf_returns_retained)
+#define CF_RETURNS_RETAINED __attribute__((cf_returns_retained))
+#else
+#define CF_RETURNS_RETAINED
+#endif
+#endif
+
+@interface MyClass : NSObject {}
+- (NSDate*) returnsCFRetained CF_RETURNS_RETAINED;
+- (NSDate*) alsoReturnsRetained;
+- (NSDate*) returnsNSRetained NS_RETURNS_RETAINED;
+@end
+
+CF_RETURNS_RETAINED
+CFDateRef returnsRetainedCFDate()  {
+  return CFDateCreate(0, CFAbsoluteTimeGetCurrent());
+}
+
+@implementation MyClass
+- (NSDate*) returnsCFRetained {
+  return (NSDate*) returnsRetainedCFDate(); // No leak.
+}
+
+- (NSDate*) alsoReturnsRetained {
+  return (NSDate*) returnsRetainedCFDate(); // Always report a leak.
+}
+
+- (NSDate*) returnsNSRetained {
+  return (NSDate*) returnsRetainedCFDate(); // Report a leak when using GC.
+}
+@end
+
+ +

Running scan-build on this example produces the following output:

+ +example returns retained + +

When the above code is compiled using Objective-C garbage collection (i.e., +code is compiled with the flag -fobjc-gc or -fobjc-gc-only), +scan-build produces both the above error (with slightly different text +to indicate the code uses garbage collection) as well as the following warning, +which indicates a leak that occurs only when using garbage +collection:

+ +example returns retained gc + +

Attribute 'cf_returns_not_retained' +(Clang-specific)

+ +

The 'cf_returns_not_retained' attribute is the complement of 'cf_returns_retained'. Where a function or +method may appear to obey the Core Foundation or Cocoa conventions and return +a retained Core Foundation object, this attribute can be used to indicate that +the object reference returned should not be considered as an +"owning" reference being returned to the caller.

+ +

Usage is identical to cf_returns_retained. When using the +attribute, be sure to declare it within the proper macro that checks for +its availability, as it is not available in earlier versions of the analyzer:

+ +
+$ cat test.m
+#ifndef __has_feature      // Optional.
+#define __has_feature(x) 0 // Compatibility with non-clang compilers.
+#endif
+
+#ifndef CF_RETURNS_NOT_RETAINED
+#if __has_feature(attribute_cf_returns_not_retained)
+#define CF_RETURNS_NOT_RETAINED __attribute__((cf_returns_not_retained))
+#else
+#define CF_RETURNS_NOT_RETAINED
+#endif
+#endif
+
+ +

Attribute 'ns_consumed' +(Clang-specific)

+ +

The 'ns_consumed' attribute can be placed on a specific parameter in either the declaration of a function or an Objective-C method. + It indicates to the static analyzer that a release message is implicitly sent to the parameter upon + completion of the call to the given function or method. + +

Important note when using Garbage Collection: Note that the analyzer +essentially ignores this attribute when code is compiled to use Objective-C +garbage collection. This is because the release message does nothing +when using GC. If the underlying function/method uses something like +CFRelease to decrement the reference count, consider using +the cf_consumed attribute instead.

+ +

Example

+ +
+$ cat test.m
+#ifndef __has_feature      // Optional.
+#define __has_feature(x) 0 // Compatibility with non-clang compilers.
+#endif
+
+#ifndef NS_CONSUMED
+#if __has_feature(attribute_ns_consumed)
+#define NS_CONSUMED __attribute__((ns_consumed))
+#else
+#define NS_CONSUMED
+#endif
+#endif
+
+void consume_ns(id NS_CONSUMED x);
+
+void test() {
+  id x = [[NSObject alloc] init];
+  consume_ns(x); // No leak!
+}
+
+@interface Foo : NSObject
++ (void) releaseArg:(id) NS_CONSUMED x;
++ (void) releaseSecondArg:(id)x second:(id) NS_CONSUMED y;
+@end
+
+void test_method() {
+  id x = [[NSObject alloc] init];
+  [Foo releaseArg:x]; // No leak!
+}
+
+void test_method2() {
+  id a = [[NSObject alloc] init];
+  id b = [[NSObject alloc] init];
+  [Foo releaseSecondArg:a second:b]; // 'a' is leaked, but 'b' is released.
+}
+
+ +

Attribute 'cf_consumed' +(Clang-specific)

+ +

The 'cf_consumed' attribute is practically identical to ns_consumed. +The attribute can be placed on a specific parameter in either the declaration of a function or an Objective-C method. +It indicates to the static analyzer that the object reference is implicitly passed to a call to CFRelease upon +completion of the call to the given function or method.

+ +

Operationally this attribute is nearly identical to ns_consumed +with the main difference that the reference count decrement still occurs when using Objective-C garbage +collection (which is import for Core Foundation types, which are not automatically garbage collected).

+ +

Example

+ +
+$ cat test.m
+#ifndef __has_feature      // Optional.
+#define __has_feature(x) 0 // Compatibility with non-clang compilers.
+#endif
+
+#ifndef CF_CONSUMED
+#if __has_feature(attribute_cf_consumed)
+#define CF_CONSUMED __attribute__((cf_consumed))
+#else
+#define CF_CONSUMED
+#endif
+#endif
+
+void consume_cf(id CF_CONSUMED x);
+void consume_CFDate(CFDateRef CF_CONSUMED x);
+
+void test() {
+  id x = [[NSObject alloc] init];
+  consume_cf(x); // No leak!
+}
+
+void test2() {
+  CFDateRef date = CFDateCreate(0, CFAbsoluteTimeGetCurrent());
+  consume_CFDate(date); // No leak, including under GC!
+  
+}
+
+@interface Foo : NSObject
++ (void) releaseArg:(CFDateRef) CF_CONSUMED x;
+@end
+
+void test_method() {
+  CFDateRef date = CFDateCreate(0, CFAbsoluteTimeGetCurrent());
+  [Foo releaseArg:date]; // No leak!
+}
+
+ +

Attribute 'ns_consumes_self' +(Clang-specific)

+ +

The 'ns_consumes_self' attribute can be placed only on an Objective-C method declaration. + It indicates that the receiver of the message is "consumed" (a single reference count decremented) + after the message is sent. This matches the semantics of all "init" methods. +

+ +

One use of this attribute is declare your own init-like methods that do not follow the + standard Cocoa naming conventions.

+ +

Example

+ +
+#ifndef __has_feature
+#define __has_feature(x) 0 // Compatibility with non-clang compilers.
+#endif
+
+#ifndef NS_CONSUMES_SELF
+#if __has_feature((attribute_ns_consumes_self))
+#define NS_CONSUMES_SELF __attribute__((ns_consumes_self))
+#else
+#define NS_CONSUMES_SELF
+#endif
+#endif
+
+@interface MyClass : NSObject
+- initWith:(MyClass *)x;
+- nonstandardInitWith:(MyClass *)x NS_CONSUMES_SELF NS_RETURNS_RETAINED;
+@end
+
+ +

In this example, nonstandardInitWith: has the same ownership semantics as the init method initWith:. + The static analyzer will observe that the method consumes the receiver, and then returns an object with a +1 retain count.

+ + +

Custom Assertion Handlers

+ + +

The analyzer exploits code assertions by pruning off paths where the +assertion condition is false. The idea is capture any program invariants +specified in the assertion that the developer may know but is not immediately +apparent in the code itself. In this way assertions make implicit assumptions +explicit in the code, which not only makes the analyzer more accurate when +finding bugs, but can help others better able to understand your code as well. +It can also help remove certain kinds of analyzer false positives by pruning off +false paths.

+ +

In order to exploit assertions, however, the analyzer must understand when it +encounters an "assertion handler." Typically assertions are +implemented with a macro, with the macro performing a check for the assertion +condition and, when the check fails, calling an assertion handler. For example, consider the following code +fragment:

+ +
+void foo(int *p) {
+  assert(p != NULL);
+}
+
+ +

When this code is preprocessed on Mac OS X it expands to the following:

+ +
+void foo(int *p) {
+  (__builtin_expect(!(p != NULL), 0) ? __assert_rtn(__func__, "t.c", 4, "p != NULL") : (void)0);
+}
+
+ +

In this example, the assertion handler is __assert_rtn. When called, +most assertion handlers typically print an error and terminate the program. The +analyzer can exploit such semantics by ending the analysis of a path once it +hits a call to an assertion handler.

+ +

The trick, however, is that the analyzer needs to know that a called function +is an assertion handler; otherwise the analyzer might assume the function call +returns and it will continue analyzing the path where the assertion condition +failed. This can lead to false positives, as the assertion condition usually +implies a safety condition (e.g., a pointer is not null) prior to performing +some action that depends on that condition (e.g., dereferencing a pointer).

+ +

The analyzer knows about several well-known assertion handlers, but can +automatically infer if a function should be treated as an assertion handler if +it is annotated with the 'noreturn' attribute or the (Clang-specific) +'analyzer_noreturn' attribute.

+ +

Attribute 'noreturn'

+ +

The 'noreturn' attribute is a GCC-attribute that can be placed on the +declarations of functions. It means exactly what its name implies: a function +with a 'noreturn' attribute should never return.

+ +

Specific details of the syntax of using the 'noreturn' attribute can be found +in GCC's +documentation.

+ +

Not only does the analyzer exploit this information when pruning false paths, +but the compiler also takes it seriously and will generate different code (and +possibly better optimized) under the assumption that the function does not +return.

+ +

Example

+ +

On Mac OS X, the function prototype for __assert_rtn (declared in +assert.h) is specifically annotated with the 'noreturn' attribute:

+ +
+void __assert_rtn(const char *, const char *, int, const char *) __attribute__((__noreturn__));
+
+ +

Attribute 'analyzer_noreturn' (Clang-specific)

+ +

The Clang-specific 'analyzer_noreturn' attribute is almost identical to +'noreturn' except that it is ignored by the compiler for the purposes of code +generation.

+ +

This attribute is useful for annotating assertion handlers that actually +can return, but for the purpose of using the analyzer we want to +pretend that such functions do not return.

+ +

Because this attribute is Clang-specific, its use should be conditioned with +the use of preprocessor macros.

+ +

Example + +

+#ifndef CLANG_ANALYZER_NORETURN
+#if __has_feature(attribute_analyzer_noreturn)
+#define CLANG_ANALYZER_NORETURN __attribute__((analyzer_noreturn))
+#else
+#define CLANG_ANALYZER_NORETURN
+#endif
+#endif
+
+void my_assert_rtn(const char *, const char *, int, const char *) CLANG_ANALYZER_NORETURN;
+
+ +
+
+ + + diff --git a/clang/www/analyzer/available_checks.html b/clang/www/analyzer/available_checks.html new file mode 100644 index 0000000..3f40d32 --- /dev/null +++ b/clang/www/analyzer/available_checks.html @@ -0,0 +1,147 @@ + + + + Available Checks + + + + + + + +
+ + +
+ +

Available Checks

+ +

The list of the checks the analyzer performs by default

+

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
core.AdjustedReturnValueCheck to see if the return value of a function call is different than the caller expects (e.g., from calls through function pointers).
core.AttributeNonNullCheck for null pointers passed as arguments to a function whose arguments are marked with the 'nonnull' attribute.
core.CallAndMessageCheck for logical errors for function calls and Objective-C message expressions (e.g., uninitialized arguments, null function pointers).
core.DivideZeroCheck for division by zero.
core.NullDereferenceCheck for dereferences of null pointers.
core.StackAddressEscapeCheck that addresses to stack memory do not escape the function.
core.UndefinedBinaryOperatorResultCheck for undefined results of binary operators.
core.VLASizeCheck for declarations of VLA of undefined or zero size.
core.builtin.BuiltinFunctionsEvaluate compiler builtin functions (e.g., alloca()).
core.builtin.NoReturnFunctionsEvaluate "panic" functions that are known to not return to the caller.
core.uninitialized.ArraySubscriptCheck for uninitialized values used as array subscripts.
core.uninitialized.AssignCheck for assigning uninitialized values.
core.uninitialized.BranchCheck for uninitialized values used as branch conditions.
core.uninitialized.CapturedBlockVariableCheck for blocks that capture uninitialized values.
core.uninitialized.UndefReturnCheck for uninitialized values being returned to the caller.
deadcode.DeadStoresCheck for values stored to variables that are never read afterwards.
deadcode.IdempotentOperationsWarn about idempotent operations.
osx.APICheck for proper uses of various Mac OS X APIs.
osx.AtomicCASEvaluate calls to OSAtomic functions.
osx.SecKeychainAPICheck for proper uses of Secure Keychain APIs.
osx.cocoa.AtSyncCheck for null pointers used as mutexes for @synchronized.
osx.cocoa.ClassReleaseCheck for sending 'retain', 'release', or 'autorelease' directly to a Class.
osx.cocoa.IncompatibleMethodTypesWarn about Objective-C method signatures with type incompatibilities.
osx.cocoa.NSAutoreleasePoolWarn for suboptimal uses of NSAutoreleasePool in Objective-C GC mode.
osx.cocoa.NSErrorCheck usage of NSError** parameters.
osx.cocoa.NilArgCheck for prohibited nil arguments to ObjC method calls.
osx.cocoa.RetainCountCheck for leaks and improper reference count management.
osx.cocoa.UnusedIvarsWarn about private ivars that are never used.
osx.cocoa.VariadicMethodTypesCheck for passing non-Objective-C types to variadic methods that expect only Objective-C types.
osx.coreFoundation.CFErrorCheck usage of CFErrorRef* parameters.
osx.coreFoundation.CFNumberCheck for proper uses of CFNumberCreate.
osx.coreFoundation.CFRetainReleaseCheck for null arguments to CFRetain/CFRelease.
unix.APICheck calls to various UNIX/Posix functions.
+ +

In addition to these the analyzer contains numerous experimental (beta) checkers.

+ +

Writeups with examples of some of the bugs that the analyzer finds

+ + + + +
+
+ + + diff --git a/clang/www/analyzer/checker_dev_manual.html b/clang/www/analyzer/checker_dev_manual.html new file mode 100644 index 0000000..fc9adf3 --- /dev/null +++ b/clang/www/analyzer/checker_dev_manual.html @@ -0,0 +1,346 @@ + + + + Checker Developer Manual + + + + + + +
+ + +
+ +

This Page Is Under Construction

+ +

Checker Developer Manual

+ +

The static analyzer engine performs symbolic execution of the program and +relies on a set of checkers to implement the logic for detecting and +constructing bug reports. This page provides hints and guidelines for anyone +who is interested in implementing their own checker. The static analyzer is a +part of the Clang project, so consult Hacking on Clang +and LLVM Programmer's Manual +for general developer guidelines and information.

+ + + +

Getting Started

+
    +
  • To check out the source code and build the project, follow steps 1-4 of + the Clang Getting Started + page.
  • + +
  • The analyzer source code is located under the Clang source tree: +
    + $ cd llvm/tools/clang + +
    See: include/clang/StaticAnalyzer, lib/StaticAnalyzer, + test/Analysis.
  • + +
  • The analyzer regression tests can be executed from the Clang's build + directory: +
    + $ cd ../../../; cd build/tools/clang; TESTDIRS=Analysis make test +
  • + +
  • Analyze a file with the specified checker: +
    + $ clang -cc1 -analyze -analyzer-checker=core.DivideZero test.c +
  • + +
  • List the available checkers: +
    + $ clang -cc1 -analyzer-checker-help +
  • + +
  • See the analyzer help for different output formats, fine tuning, and + debug options: +
    + $ clang -cc1 -help | grep "analyzer" +
  • + +
+ +

Static Analyzer Overview

+ The analyzer core performs symbolic execution of the given program. All the + input values are represented with symbolic values; further, the engine deduces + the values of all the expressions in the program based on the input symbols + and the path. The execution is path sensitive and every possible path through + the program is explored. The explored execution traces are represented with + ExplidedGraph object. + Each node of the graph is + ExplodedNode, + which consists of a ProgramPoint and a ProgramState. +

+ ProgramPoint + represents the corresponding location in the program (or the CFG graph). + ProgramPoint is also used to record additional information on + when/how the state was added. For example, PostPurgeDeadSymbolsKind + kind means that the state is the result of purging dead symbols - the + analyzer's equivalent of garbage collection. +

+ ProgramState + represents abstract state of the program. It consists of: +

    +
  • Environment - a mapping from source code expressions to symbolic + values +
  • Store - a mapping from memory locations to symbolic values +
  • GenericDataMap - constraints on symbolic values +
+ +

Interaction with Checkers

+ Checkers are not merely passive receivers of the analyzer core changes - they + actively participate in the ProgramState construction through the + GenericDataMap which can be used to store the checker-defined part + of the state. Each time the analyzer engine explores a new statement, it + notifies each checker registered to listen for that statement, giving it an + opportunity to either report a bug or modify the state. (As a rule of thumb, + the checker itself should be stateless.) The checkers are called one after another + in the predefined order; thus, calling all the checkers adds a chain to the + ExplodedGraph. + +

Representing Values

+ During symbolic execution, SVal + objects are used to represent the semantic evaluation of expressions. They can + represent things like concrete integers, symbolic values, or memory locations + (which are memory regions). They are a discriminated union of "values", + symbolic and otherwise. +

+ SymExpr (symbol) + is meant to represent abstract, but named, symbolic value. + Symbolic values can have constraints associated with them. Symbols represent + an actual (immutable) value. We might not know what its specific value is, but + we can associate constraints with that value as we analyze a path. +

+ + MemRegion is similar to a symbol. + It is used to provide a lexicon of how to describe abstract memory. Regions can + layer on top of other regions, providing a layered approach to representing memory. + For example, a struct object on the stack might be represented by a VarRegion, + but a FieldRegion which is a subregion of the VarRegion could + be used to represent the memory associated with a specific field of that object. + So how do we represent symbolic memory regions? That's what SymbolicRegion + is for. It is a MemRegion that has an associated symbol. Since the + symbol is unique and has a unique name; that symbol names the region. +

+ Let's see how the analyzer processes the expressions in the following example: +

+

+  int foo(int x) {
+     int y = x * 2;
+     int z = x;
+     ...
+  }
+  
+

+Let's look at how x*2 gets evaluated. When x is evaluated, +we first construct an SVal that represents the lvalue of x, in +this case it is an SVal that references the MemRegion for x. +Afterwards, when we do the lvalue-to-rvalue conversion, we get a new SVal, +which references the value currently bound to x. That value is +symbolic; it's whatever x was bound to at the start of the function. +Let's call that symbol $0. Similarly, we evaluate the expression for 2, +and get an SVal that references the concrete number 2. When +we evaluate x*2, we take the two SVals of the subexpressions, +and create a new SVal that represents their multiplication (which in +this case is a new symbolic expression, which we might call $1). When we +evaluate the assignment to y, we again compute its lvalue (a MemRegion), +and then bind the SVal for the RHS (which references the symbolic value $1) +to the MemRegion in the symbolic store. +
+The second line is similar. When we evaluate x again, we do the same +dance, and create an SVal that references the symbol $0. Note, two SVals +might reference the same underlying values. + +

+To summarize, MemRegions are unique names for blocks of memory. Symbols are +unique names for abstract symbolic values. Some MemRegions represents abstract +symbolic chunks of memory, and thus are also based on symbols. SVals are just +references to values, and can reference either MemRegions, Symbols, or concrete +values (e.g., the number 1). + + +

Idea for a Checker

+ Here are several questions which you should consider when evaluating your + checker idea: +
    +
  • Can the check be effectively implemented without path-sensitive + analysis? See AST Visitors.
  • + +
  • How high the false positive rate is going to be? Looking at the occurrences + of the issue you want to write a checker for in the existing code bases might + give you some ideas.
  • + +
  • How the current limitations of the analysis will effect the false alarm + rate? Currently, the analyzer only reasons about one procedure at a time (no + inter-procedural analysis). Also, it uses a simple range tracking based + solver to model symbolic execution.
  • + +
  • Consult the Bugzilla database + to get some ideas for new checkers and consider starting with improving/fixing + bugs in the existing checkers.
  • +
+ +

Checker Registration

+ All checker implementation files are located in clang/lib/StaticAnalyzer/Checkers + folder. Follow the steps below to register a new checker with the analyzer. +
    +
  1. Create a new checker implementation file, for example ./lib/StaticAnalyzer/Checkers/NewChecker.cpp +
    +using namespace clang;
    +using namespace ento;
    +
    +namespace {
    +class NewChecker: public Checker< check::PreStmt<CallExpr> > {
    +public:
    +  void checkPreStmt(const CallExpr *CE, CheckerContext &Ctx) const {}
    +}
    +}
    +void ento::registerNewChecker(CheckerManager &mgr) {
    +  mgr.registerChecker<NewChecker>();
    +}
    +
    + +
  2. Pick the package name for your checker and add the registration code to +./lib/StaticAnalyzer/Checkers/Checkers.td. Note, all checkers should +first be developed as experimental. Suppose our new checker performs security +related checks, then we should add the following lines under +SecurityExperimental package: +
    +let ParentPackage = SecurityExperimental in {
    +...
    +def NewChecker : Checker<"NewChecker">,
    +  HelpText<"This text should give a short description of the checks performed.">,
    +  DescFile<"NewChecker.cpp">;
    +...
    +} // end "security.experimental"
    +
    + +
  3. Make the source code file visible to CMake by adding it to +./lib/StaticAnalyzer/Checkers/CMakeLists.txt. + +
  4. Compile and see your checker in the list of available checkers by running:
    +$clang -cc1 -analyzer-checker-help +
+ + +

Checker Skeleton

+ There are two main decisions you need to make: +
    +
  • Which events the checker should be tracking. + See CheckerDocumentation + for the list of available checker callbacks.
  • +
  • What data you want to store as part of the checker-specific program + state. Try to minimize the checker state as much as possible.
  • +
+ +

Bug Reports

+ +

AST Visitors

+ Some checks might not require path-sensitivity to be effective. Simple AST walk + might be sufficient. If that is the case, consider implementing a Clang + compiler warning. On the other hand, a check might not be acceptable as a compiler + warning; for example, because of a relatively high false positive rate. In this + situation, AST callbacks checkASTDecl and + checkASTCodeBody are your best friends. + +

Testing

+ Every patch should be well tested with Clang regression tests. The checker tests + live in clang/test/Analysis folder. To run all of the analyzer tests, + execute the following from the clang build directory: +
+    $ TESTDIRS=Analysis make test
+    
+ +

Useful Commands/Debugging Hints

+
    +
  • +While investigating a checker-related issue, instruct the analyzer to only +execute a single checker: +
    +$ clang -cc1 -analyze -analyzer-checker=osx.KeychainAPI test.c + +
  • +
  • +To dump AST: +
    +$ clang -cc1 -ast-dump test.c + +
  • +
  • +To view/dump CFG use debug.ViewCFG or debug.DumpCFG checkers: +
    +$ clang -cc1 -analyze -analyzer-checker=debug.ViewCFG test.c + +
  • +
  • +To see all available debug checkers: +
    +$ clang -cc1 -analyzer-checker-help | grep "debug" + +
  • +
  • +To see which function is failing while processing a large file use +-analyzer-display-progress option. +
  • +
  • +While debugging execute clang -cc1 -analyze -analyzer-checker=core +instead of clang --analyze, as the later would call the compiler +in a separate process. +
  • +
  • +To view ExplodedGraph (the state graph explored by the analyzer) while +debugging, goto a frame that has clang::ento::ExprEngine object and +execute: +
    +(gdb) p ViewGraph(0) + +
  • +
  • +To see the ProgramState while debugging use the following command. +
    +(gdb) p State->dump() + +
  • +
  • +To see clang::Expr while debugging use the following command. If you +pass in a SourceManager object, it will also dump the corresponding line in the +source code. +
    +(gdb) p E->dump() + +
  • +
  • +To dump AST of a method that the current ExplodedNode belongs to: +
    +(gdb) p C.getPredecessor()->getCodeDecl().getBody()->dump() +(gdb) p C.getPredecessor()->getCodeDecl().getBody()->dump(getContext().getSourceManager()) + +
  • +
+ +
+
+ + diff --git a/clang/www/analyzer/content.css b/clang/www/analyzer/content.css new file mode 100644 index 0000000..b22cca9 --- /dev/null +++ b/clang/www/analyzer/content.css @@ -0,0 +1,79 @@ +html { margin: 0px; } body { margin: 8px; } + +html, body { + padding:0px; + margin:0px; + font-size:small; font-family:"Lucida Grande", "Lucida Sans Unicode", Arial, Verdana, Helvetica, sans-serif; background-color: #fff; color: #222; + line-height:1.5; + background-color: #808080; + +} + +h1, h2, h3, tt { color: #000 } + +h1 { padding-top:0px; margin-top:0px;} +h2 { color:#333333; padding-top:0.5em; } +h3 { padding-top: 0.5em; margin-bottom: -0.25em; color:#2d58b7 } +h4 { color:#2d58b7 } +li { padding-bottom: 0.5em } +ul { padding-left:1.5em; } + +.command { font-weight:bold } +.code_highlight { font-weight:bold; color:#2d58b7 } +.code_example { border-width:1px; border-style:solid; border-color:#cccccc; + background-color:#eeeeee; padding:10px } + +/* Slides */ +IMG.img_slide { + display: block; + margin-left: auto; + margin-right: auto +} + +#page { width:930px; text-align: left; margin: 0 auto; padding:0; + background-color: white; height:100%; + border-left: 1px solid #EBF0FA; +} + +#content { + clear: left; + padding: 1em 2em 0 2em; + background-color: #ffffff; +} + +.itemTitle { color:#2d58b7 } + + +/* Tables */ +tr { vertical-align:top } + +table.options thead { + background-color:#eee; color:#666666; + font-weight: bold; cursor: default; + text-align:left; + border-top: 2px solid #cccccc; + border-bottom: 2px solid #cccccc; + font-weight: bold; font-family: Verdana +} +table.options { border: 1px #cccccc solid } +table.options { border-collapse: collapse; border-spacing: 0px } +table.options { margin-left:0px; margin-top:20px; margin-bottom:20px } +table.options td { border-bottom: 1px #cccccc dotted } +table.options td { padding:5px; padding-left:8px; padding-right:8px } +table.options td { text-align:left; font-size:9pt } + +/* Collapsing Trees: http://dbtree.megalingo.com/web/demo/simple-collapsible-tree.cfm */ +#collapsetree, #collapsetree a:link, #collapsetree li a:link, #collapsetree a:visited, #collapsetree li a:visited{color:#000;text-decoration:none} +#collapsetree,#collapsetree ul{list-style-type:none; width:auto; margin:0; padding:0} +#collapsetree ul{padding-left:20px;display:none;overflow:auto} +#collapsetree li ul{margin:0 auto} +#collapsetree li{display:block;width:100%;line-height:20px;white-space:nowrap} +#collapsetree li a{display:block;padding-left:20px;color:#000;text-decoration:none;background:url(images/tree/bullet.gif) center left no-repeat;white-space:nowrap} +#collapsetree li a:hover{text-decoration:underline;background-color:transparent;color:#000} +#collapsetree li ul.click{display:block} +#collapsetree li.click a{background:url(images/tree/bullet.gif) center left no-repeat} +#collapsetree ul li.click a{background:url(images/tree/bullet.gif) center left no-repeat} +#collapsetree li a.subMenu,#collapsetree ul li a.subMenu{background:url(images/tree/plus.gif) center left no-repeat} +#collapsetree li a.click{background:url(images/tree/minus.gif) center left no-repeat} +#collapsetree ul li a.click{background:url(images/tree/minus.gif) center left no-repeat} + diff --git a/clang/www/analyzer/dev_cxx.html b/clang/www/analyzer/dev_cxx.html new file mode 100644 index 0000000..39dbf7b --- /dev/null +++ b/clang/www/analyzer/dev_cxx.html @@ -0,0 +1,54 @@ + + + + Analyzer Development: C++ Support + + + + + + +
+ +
+ +

C++ Support

+ +

The Clang frontend +now supports the +majority of C++. Support in the frontend for C++ language +features, however, does not automatically translate into support for +those features in the static analyzer. Language features need to be +specifically modeled in the static analyzer so their semantics can be +properly analyzed. Support for analyzing C++ and Objective-C++ files +is currently extremely limited, and we are only encouraging those who +are interested in contributing to the development of the analyzer to +try this functionality out at this time.

+ +

Listed here are a set of open tasks that are prerequisites for +decent analysis of C++. This list is also not complete; new tasks +will be added as deemed necessary.

+ +
    +
  • Control-Flow Graph Enhancements: +
      +
    • Model C++ destructors
    • +
    • Model C++ initializers (in constructors)
    • +
    +
  • +
  • Path-Sensitive Analysis Engine (GRExprEngine): +
      +
    • Model C++ casts
    • +
    • Model C++ constructors
    • +
    • Model C++ destructors
    • +
    • Model new and delete
    • +
    +
  • +
+ +
+
+ + + diff --git a/clang/www/analyzer/filing_bugs.html b/clang/www/analyzer/filing_bugs.html new file mode 100644 index 0000000..f32a8ab --- /dev/null +++ b/clang/www/analyzer/filing_bugs.html @@ -0,0 +1,62 @@ + + + + Filing Bugs and Feature Requests + + + + + + +
+ +
+ +

Filing Bugs and Feature Requests

+ +

We encourage users to file bug reports for any problems that they encounter. +We also welcome feature requests. When filing a bug report, please do the +following:

+ +
    + +
  • Include the checker build (for prebuilt Mac OS X binaries) or the SVN +revision number.
  • + +
  • Provide a self-contained, reduced test case that exhibits the issue you are +experiencing.
  • + +
  • Test cases don't tell us everything. Please briefly describe the problem you +are seeing, including what you thought should have been the expected behavior +and why.
  • + +
+ +

Outside of Apple

+ +

Bugzilla

+ +

Please file +bugs in LLVM's Bugzilla database against the Clang Static Analyzer +component.

+ +

Bugreporter.apple.com

+ +

If you are using the analyzer to analyze code associated with an Apple NDA +(e.g., preview versions of SDKs or seed releases of Mac OS X) please file bug +reports to Apple's Bug Reporter web +site.

+ +

You are free to always file bugs through this website, but this option is less +attractive than filing bug reports through Bugzilla as not everyone who works on +the analyzer has access to that bug database.

+ +

Apple-internal Users

+ +

Please file bugs in Radar against the clang - static analyzer component.

+
+
+ + + diff --git a/clang/www/analyzer/images/analyzer_html.png b/clang/www/analyzer/images/analyzer_html.png new file mode 100644 index 0000000..607ea18 Binary files /dev/null and b/clang/www/analyzer/images/analyzer_html.png differ diff --git a/clang/www/analyzer/images/analyzer_xcode.png b/clang/www/analyzer/images/analyzer_xcode.png new file mode 100644 index 0000000..84c6980 Binary files /dev/null and b/clang/www/analyzer/images/analyzer_xcode.png differ diff --git a/clang/www/analyzer/images/example_attribute_nonnull.png b/clang/www/analyzer/images/example_attribute_nonnull.png new file mode 100644 index 0000000..919af61 Binary files /dev/null and b/clang/www/analyzer/images/example_attribute_nonnull.png differ diff --git a/clang/www/analyzer/images/example_cf_returns_retained.png b/clang/www/analyzer/images/example_cf_returns_retained.png new file mode 100644 index 0000000..4bee499 Binary files /dev/null and b/clang/www/analyzer/images/example_cf_returns_retained.png differ diff --git a/clang/www/analyzer/images/example_cf_returns_retained_gc.png b/clang/www/analyzer/images/example_cf_returns_retained_gc.png new file mode 100644 index 0000000..023f1a2 Binary files /dev/null and b/clang/www/analyzer/images/example_cf_returns_retained_gc.png differ diff --git a/clang/www/analyzer/images/example_ns_returns_retained.png b/clang/www/analyzer/images/example_ns_returns_retained.png new file mode 100644 index 0000000..61316e1 Binary files /dev/null and b/clang/www/analyzer/images/example_ns_returns_retained.png differ diff --git a/clang/www/analyzer/images/scan_build_cmd.png b/clang/www/analyzer/images/scan_build_cmd.png new file mode 100644 index 0000000..464fd4e Binary files /dev/null and b/clang/www/analyzer/images/scan_build_cmd.png differ diff --git a/clang/www/analyzer/images/tree/bullet.gif b/clang/www/analyzer/images/tree/bullet.gif new file mode 100644 index 0000000..de15348 Binary files /dev/null and b/clang/www/analyzer/images/tree/bullet.gif differ diff --git a/clang/www/analyzer/images/tree/minus.gif b/clang/www/analyzer/images/tree/minus.gif new file mode 100644 index 0000000..225f40d Binary files /dev/null and b/clang/www/analyzer/images/tree/minus.gif differ diff --git a/clang/www/analyzer/images/tree/plus.gif b/clang/www/analyzer/images/tree/plus.gif new file mode 100644 index 0000000..5398c80 Binary files /dev/null and b/clang/www/analyzer/images/tree/plus.gif differ diff --git a/clang/www/analyzer/index.html b/clang/www/analyzer/index.html new file mode 100644 index 0000000..18bafd0 --- /dev/null +++ b/clang/www/analyzer/index.html @@ -0,0 +1,224 @@ + + + + Clang Static Analyzer + + + + + + + + + +
+ +
+ + + +
+ +

Clang Static Analyzer

+ +

The Clang Static Analyzer is source code analysis tool that find bugs in C +and Objective-C programs.

+ +

Currently it can be run either as a standalone +tool or within Xcode. The standalone tool is +invoked from the command-line, and is intended to be run in tandem with a build +of a codebase.

+ +

The analyzer is 100% open source and is part of the Clang project. Like the rest of Clang, the +analyzer is implemented as a C++ library that can be used by other tools and +applications.

+ +

Download

+ +
+ + + + + + +
+
+

Mac OS X

+
    +
  • Latest build (Intel-only binary, 10.5+):
    + +
  • +
  • Release notes
  • +
  • This build can be used both from the command line and from within Xcode
  • +
  • Installation and usage
  • +
+
+
+ + + + + + +
+ +
+ + + + + + +
+
+

Other Platforms

+

For other platforms, please follow the instructions for building the analyzer from + source code.

+

+
+ + + + + + +
+ + +
+analyzer in xcode +
Viewing static analyzer results in Xcode 3.2
+analyzer in browser +
Viewing static analyzer results in a web browser
+
+ +

What is Static Analysis?

+ +

The term "static analysis" is conflated, but here we use it to mean +a collection of algorithms and techniques used to analyze source code in order +to automatically find bugs. The idea is similar in spirit to compiler warnings +(which can be useful for finding coding errors) but to take that idea a step +further and find bugs that are traditionally found using run-time debugging +techniques such as testing.

+ +

Static analysis bug-finding tools have evolved over the last several decades +from basic syntactic checkers to those that find deep bugs by reasoning about +the semantics of code. The goal of the Clang Static Analyzer is to provide a +industrial-quality static analysis framework for analyzing C and Objective-C +programs that is freely available, extensible, and has a high quality of +implementation.

+ +

Part of Clang and LLVM

+ +

As its name implies, the Clang Static Analyzer is built on top of Clang and LLVM. +Strictly speaking, the analyzer is part of Clang, as Clang consists of a set of +reusable C++ libraries for building powerful source-level tools. The static +analysis engine used by the Clang Static Analyzer is a Clang library, and has +the capability to be reused in different contexts and by different clients.

+ +

Important Points to Consider

+ +

While we believe that the static analyzer is already very useful for finding +bugs, we ask you to bear in mind a few points when using it.

+ +

Work-in-Progress

+ +

The analyzer is a continuous work-in-progress. +There are many planned enhancements to improve both the precision and scope of +its analysis algorithms as well as the kinds bugs it will find. While there are +fundamental limitations to what static analysis can do, we have a long way to go +before hitting that wall.

+ +

Slower than Compilation

+ +

Operationally, using static analysis to +automatically find deep program bugs is about trading CPU time for the hardening +of code. Because of the deep analysis performed by state-of-the-art static +analysis tools, static analysis can be much slower than compilation.

+ +

While the Clang Static Analyzer is being designed to be as fast and +light-weight as possible, please do not expect it to be as fast as compiling a +program (even with optimizations enabled). Some of the algorithms needed to find +bugs require in the worst case exponential time.

+ +

The Clang Static Analyzer runs in a reasonable amount of time by both +bounding the amount of checking work it will do as well as using clever +algorithms to reduce the amount of work it must do to find bugs.

+ +

False Positives

+ +

Static analysis is not perfect. It can falsely flag bugs in a program where +the code behaves correctly. Because some code checks require more analysis +precision than others, the frequency of false positives can vary widely between +different checks. Our long-term goal is to have the analyzer have a low false +positive rate for most code on all checks.

+ +

Please help us in this endeavor by reporting false +positives. False positives cannot be addressed unless we know about +them.

+ +

More Checks

+ +

Static analysis is not magic; a static analyzer can only find bugs that it +has been specifically engineered to find. If there are specific kinds of bugs +you would like the Clang Static Analyzer to find, please feel free to +file feature requests or contribute your own +patches.

+ +
+
+ + + diff --git a/clang/www/analyzer/installation.html b/clang/www/analyzer/installation.html new file mode 100644 index 0000000..ebccd07 --- /dev/null +++ b/clang/www/analyzer/installation.html @@ -0,0 +1,114 @@ + + + + Obtaining the Static Analyzer + + + + + + +
+ +
+ +

Obtaining the Static Analyzer

+ +

This page describes how to download and install the analyzer. Once +the analyzer is installed, follow the instructions on using scan-build to +get started analyzing your code.

+ +

Packaged Builds (Mac OS X)

+ +

Semi-regular pre-built binaries of the analyzer are available on Mac +OS X. These are built to run on Mac OS 10.5 and later.

+ +

Builds are released frequently. Often the differences between build +numbers being a few bug fixes or minor feature improvements. When using +the analyzer, we recommend that you check back here occasionally for new +builds, especially if the build you are using is more than a couple +weeks old.

+ +

The latest build is: + +

+ +

Packaged builds for other platforms may eventually be provided, but +we need volunteers who are willing to help provide such regular builds. +If you wish to help contribute regular builds of the analyzer on other +platforms, please email the Clang +Developers' mailing list.

+ +

Using Packaged Builds

+ +

To use a package build, simply unpack it anywhere. If the build +archive has the name checker-XXX.tar.bz2 then the +archive will expand to a directory called checker-XXX. +You do not need to place this directory or the contents of this +directory in any special place. Uninstalling the analyzer is as simple +as deleting this directory.

+ +

Most of the files in the checker-XXX directory will +be supporting files for the analyzer that you can simply ignore. Most +users will only care about two files, which are located at the top of +the checker-XXX directory:

+ +
    +
  • scan-build: scan-build is the high-level command line utility for running the analyzer
  • +
  • scan-view: scan-view a companion comannd line +utility to scan-build, scan-view is used to view +analysis results generated by scan-build. There is an option +that one can pass to scan-build to cause scan-view to +run as soon as it the analysis of a build completes
  • +
+ +

Running scan-build

+ +

For specific details on using scan-build, please see +scan-build's documentation.

+ +

To run scan-build, either add the +checker-XXX directory to your path or specify a complete +path for scan-build when running it. It is also possible to use +a symbolic link to scan-build, such one located in a directory +in your path. When scan-build runs it will automatically +determine where to find its accompanying files.

+ +

Other Platforms (Building the Analyzer from Source)

+ +

For other platforms, you must build Clang and LLVM manually. To do +so, please follow the instructions for building Clang from +source code.

+ +

Once the Clang is built, you need to add the following to your path:

+ +
    + +
  • The location of the clang binary. + +

    For example, if you built a Debug+Asserts build of LLVM/Clang (the +default), the resultant clang binary will be in $(OBJDIR)/Debug+Asserts/bin +(where $(OBJDIR) is often the same as the root source directory). You +can also do make install to install the LLVM/Clang libaries and +binaries to the installation directory of your choice (specified when you run +configure).

  • + +
  • The locations of the scan-build and scan-view +programs. + +

    Currently these are not installed using make install, and +are located in $(SRCDIR)/tools/clang/tools/scan-build and +$(SRCDIR)/tools/clang/tools/scan-view respectively (where +$(SRCDIR) is the root LLVM source directory). These locations +are subject to change.

  • + +
+
+
+ + + diff --git a/clang/www/analyzer/latest_checker.html.incl b/clang/www/analyzer/latest_checker.html.incl new file mode 100644 index 0000000..d1b0d06 --- /dev/null +++ b/clang/www/analyzer/latest_checker.html.incl @@ -0,0 +1 @@ +checker-263.tar.bz2 (built March 22, 2012) diff --git a/clang/www/analyzer/menu.css b/clang/www/analyzer/menu.css new file mode 100644 index 0000000..05c1bbf --- /dev/null +++ b/clang/www/analyzer/menu.css @@ -0,0 +1,52 @@ +/* From 'A list apart', 'dropdowns' */ + +#nav { + clear: left; + margin:0; + padding:0; + font-weight: bold; + width:100%; + background-color: #EBF0FA; + border-bottom: 1px solid; + font-size: 80%; +} +#nav a { + text-decoration: none; +} +#nav a:hover { + text-decoration: underline; +} +.menubar ul { + list-style: none inside; +} +.menubar li { + margin: 0; + padding: 5px; + text-align: left; + text-indent: 0px; + list-style-position: inside; + list-style:none; + float: left; + position: relative; + width: 13em; + cursor: default; + background-color: #EBF0FA; +} +.menubar li ul /* second level lists */ { + display: none; + position: absolute; + left: 0; +} +.menubar li>ul { + border-left: 1px solid; + border-right: 1px solid; + border-bottom: 1px solid; + padding: 0; + margin: 5px 0; + left:auto; + font-weight: normal; +} +.menubar li:hover ul, li.over ul { /* lists nested under hovered list items */ + display: block; +} + diff --git a/clang/www/analyzer/menu.html.incl b/clang/www/analyzer/menu.html.incl new file mode 100644 index 0000000..53a4276 --- /dev/null +++ b/clang/www/analyzer/menu.html.incl @@ -0,0 +1,41 @@ + + + diff --git a/clang/www/analyzer/release_notes.html b/clang/www/analyzer/release_notes.html new file mode 100644 index 0000000..42de9dd --- /dev/null +++ b/clang/www/analyzer/release_notes.html @@ -0,0 +1,188 @@ + + + + Release notes for checker-XXX builds + + + + + + +
+ +
+ +

Release notes for checker-XXX builds

+ +

checker-263

+ +

built: March 22, 2012
+ download: checker-263.tar.bz2

+

highlights:

+ +
    +
  • Fixes several serious bugs with inter-procedural analysis, including a case where retain/releases would be "double-counted".
  • +
+ +

checker-262

+ +

built: March 15, 2012
+ download: checker-262.tar.bz2

+

highlights:

+ +
    +
  • Enables experimental interprocedural analysis (within a file), which greatly amplifies the analyzer's ability to find issues.
  • +
  • Many bug fixes to the malloc/free checker.
  • +
  • Support for new Objective-C NSArray/NSDictionary/NSNumber literals syntax, and Objective-C container subscripting.
  • +
+ +

NOTE: This build contains new interprocedural analysis that allows the analyzer to find more complicated bugs that span function boundaries. It may have problems, performance issues, etc. We'd like to hear about them. + +

checker-261

+ +

built: February 22, 2012
+download: checker-261.tar.bz2

+

highlights:

+ +
    +
  • Contains a new experimental malloc/free checker.
  • +
  • Better support for projects using ARC.
  • +
  • Warns about null pointers passed as arguments to C string functions.
  • +
  • Warns about common anti-patterns in 'strncat' size argument, which can lead to buffer overflows.
  • +
  • set-xcode-analyzer now supports self-contained Xcode.app (Xcode 4.3 and later).
  • +
  • Contains a newer version of the analyzer than Xcode 4.3.
  • +
  • Misc. bug fixes and performance work.
  • +
+ +

checker-260

+ +

built: January 25, 2012
+download: checker-260.tar.bz2

+

highlights:

+ +

This is essentially the same as checker-259, but enables the following experimental checkers (please provide feedback):

+ +
    +
  • Warns about unsafe uses of CFArrayCreate, CFSetCreate, and CFDictionaryCreate
  • +
  • Warns about unsafe uses of getpw, gets, which are sources of buffer overflows
  • +
  • Warns about unsafe uses of mktemp and mktemps, which can lead to insecure temporary files
  • +
  • Warns about unsafe uses of vfork, which is insecure to use
  • +
  • Warns about not checking the return values of setuid, setgid, seteuid, setegid, setreuid, setregid (another security issue)
  • +
+ +

checker-259

+ +

built: January 25, 2012
+download: checker-259.tar.bz2

+

highlights:

+ +
    +
  • Contains a newer version of the analyzer than the one shipped in Xcode 4.2.
  • +
  • Significant performance optimizations to reduce memory usage of the analyzer.
  • +
  • Tweaks to scan-build to have it work more easily with Xcode projects using Clang.
  • +
  • Numerous bug fixes to better support code using ARC.
  • +
+ +

checker-258

+ +

built: October 13, 2011
+

highlights:

+ +
    +
  • Contains a newer version of the analyzer than the one shipped in Xcode 4.2.
  • +
  • Adds a new security checker for looking at correct uses of the Mac OS KeyChain API.
  • +
  • Supports ARC (please file bugs where you see issues)
  • +
  • Major under-the-cover changes. This should result in more precise results in some cases, but this is laying the groundwork for major improvements. Please file bugs where you see regressions or issues.
  • +
+ +

checker-257

+ +

built: May 25, 2011
+

highlights:

+ +
    +
  • The analyzer is now far more aggressive with checking conformance with Core Foundation conventions. Any function that returns a CF type must now obey the Core Foundation naming conventions, or use the cf_returns_retained or cf_returns_not_retained annotations.
  • +
  • Fixed a serious regression where the analyzer would not analyze Objective-C methods in class extensions.
  • +
  • Misc. bug fixes to improve analyzer precision. +
  • +
+ +

checker-256

+ +

built: April 13, 2011
+

highlights:

+ +
    +
  • Lots of bug fixes and improvements to analyzer precision (fewer false positives, possibly more bugs found). +
  • Introductory analysis support for C++ and Objective-C++. +
+ +

This build contains basic support for C++ and Objective-C++ that is ready to be tried out + by general users. It is still in its infancy, but establishes a baseline for things to come. The main hope is that it can find some + issues and have a reasonable false positive rate.

+ +

Please file bugs when you see issues of any kind so we can assess + where development on C++ analysis support needs to be focused.

+ +

To try out C++ analysis support, it should work out of the box using scan-build. If you are using this checker build + as a replacement to the analyzer bundled with Xcode, first use the set-xcode-analyzer script to change Xcode to use + your version of the analyzer. You will then need to modify one configuration file in Xcode to enable C++ analysis support. This can + be done with the following steps:

+ +
    +
  1. Find the clang .xcspec file: +
    $ cd /Developer/Library
    +$ find . | grep xcspec | grep Clang
    +./Xcode/<SNIP>/Clang LLVM 1.0.xcplugin/Contents/Resources/Clang LLVM 1.0.xcspec
    +
  2. +
  3. The exact location of the file may vary depending on your installation of Xcode. Edit that file, and look for the string "--analyze": +
    +  SourceFileOption = "--analyze";
    +  FileTypes = (
    +      "sourcecode.c.c",
    +      "sourcecode.c.objc",
    +  );
    +  ...
    +
    + Change the "FileTypes" entry to: +
    +  FileTypes = (
    +      "sourcecode.c.c",
    +      "sourcecode.c.objc",
    +      "sourcecode.cpp.cpp",
    +      "sourcecode.cpp.objcpp",
    +  );
    +
  4. +
  5. Restart Xcode.
  6. +
+ +

checker-255

+ +

built: February 11, 2011
+

highlights:

+ +
    +
  • Mac OS X builds are now Intel i386 and x86_64 only (no ppc support)
  • +
  • Turns on new -init method checker by default
  • +
  • Reduces memory usage of analyzer by 10%
  • +
  • Misc. fixes to reduce false positives on dead stores and idempotent operations.
  • +
+ +

checker-254

+ +

built: January 27, 2011
+

highlights:

+ +
    +
  • Introduces new -init method checker to check if a super class's init method is properly called.
  • +
  • Objective-C retain/release checker now reasons about calls to property accessor methods (setter/getter).
  • +
  • Introduces new attribute ns_consumes_self to educate the Objective-C retain/release checker about custom "init-like" methods that do not follow the standard Cocoa naming conventions.
  • +
  • Introduces new attributes ns_consumed and cf_consumed to educate the Objective-C retain/release checker about methods/functions that decrement the reference count of a parameter.
  • +
+ +
+
+ + + diff --git a/clang/www/analyzer/scan-build.html b/clang/www/analyzer/scan-build.html new file mode 100644 index 0000000..710fa0f --- /dev/null +++ b/clang/www/analyzer/scan-build.html @@ -0,0 +1,344 @@ + + + + scan-build: running the analyzer from the command line + + + + + + + +
+ +
+ +

scan-build: running the analyzer from the command line

+ + + +
+ +

What is it?

+

scan-build is a command line utility that enables a user to run the +static analyzer over their codebase as part of performing a regular build (from +the command line).

+ +

How does it work?

+

During a project build, as source files are compiled they are also analyzed +in tandem by the static analyzer.

+ +

Upon completion of the build, results are then presented to the user within a +web browser.

+ +

Will it work with any build system?

+

scan-build has little or no knowledge about how you build your code. +It works by overriding the CC and CXX environment variables to +(hopefully) change your build to use a "fake" compiler instead of the +one that would normally build your project. This fake compiler executes either +clang or gcc (depending on the platform) to compile your +code and then executes the static analyzer to analyze your code.

+ +

This "poor man's interposition" works amazingly well in many cases +and falls down in others. Please consult the information on this page on making +the best use of scan-build, which includes getting it to work when the +aforementioned hack fails to work.

+ +
+ scan-build
+ analyzer in browser +
Viewing static analyzer results in a web browser +
+ +

Contents

+ + + +

Getting Started

+ +

The scan-build command can be used to analyze an entire project by +essentially interposing on a project's build process. This means that to run the +analyzer using scan-build, you will use scan-build to analyze +the source files compiled by gcc/clang during a project build. +This means that any files that are not compiled will also not be analyzed.

+ +

Basic Usage

+ +

Basic usage of scan-build is designed to be simple: just place the +word "scan-build" in front of your build command:

+ +
+$ scan-build make
+$ scan-build xcodebuild
+
+ +

In the first case scan-build analyzes the code of a project built +with make and in the second case scan-build analyzes a project +built using xcodebuild.

+ +

Here is the general format for invoking scan-build:

+ +
+$ scan-build [scan-build options] <command> [command options]
+
+ +

Operationally, scan-build literally runs <command> with all of the +subsequent options passed to it. For example, one can pass -j4 to +make get a parallel build over 4 cores:

+ +
+$ scan-build make -j4
+
+ +

In almost all cases, scan-build makes no effort to interpret the +options after the build command; it simply passes them through. In general, +scan-build should support parallel builds, but not distributed +builds.

+ +

It is also possible to use scan-build to analyze specific +files:

+ +
+ $ scan-build gcc -c t1.c t2.c
+
+ +

This example causes the files t1.c and t2.c to be analyzed. +

+ +

Other Options

+ +

As mentioned above, extra options can be passed to scan-build. These +options prefix the build command. For example:

+ +
+ $ scan-build -k -V make
+ $ scan-build -k -V xcodebuild
+
+ +

Here is a subset of useful options:

+ + + + + + + + + + + + +
OptionDescription
-oTarget directory for HTML report files. Subdirectories +will be created as needed to represent separate "runs" of the analyzer. If this +option is not specified, a directory is created in /tmp to store the +reports.
-h
(or no arguments)
Display all +scan-build options.
-k
--keep-going
Add a "keep on +going" option to the specified build command.

This option currently supports +make and xcodebuild.

This is a convenience option; one +can specify this behavior directly using build options.

-vVerbose output from scan-build and the analyzer. A +second and third "-v" increases verbosity, and is useful for filing bug +reports against the analyzer.
-VView analysis results in a web browser when the build +command completes.
+ +

A complete list of options can be obtained by running scan-build +with no arguments.

+ +

Output of scan-build

+ +

+The output of scan-build is a set of HTML files, each one which represents a +separate bug report. A single index.html file is generated for +surveying all of the bugs. You can then just open index.html in a web +browser to view the bug reports. +

+ +

+Where the HTML files are generated is specified with a -o option to +scan-build. If -o isn't specified, a directory in /tmp +is created to store the files (scan-build will print a message telling +you where they are). If you want to view the reports immediately after the build +completes, pass -V to scan-build. +

+ + +

Recommended Usage Guidelines

+ +

This section describes a few recommendations with running the analyzer.

+ + + +

Most projects can be built in a "debug" mode that enables assertions. +Assertions are picked up by the static analyzer to prune infeasible paths, which +in some cases can greatly reduce the number of false positives (bogus error +reports) emitted by the tool.

+ +

Use verbose output when debugging scan-build

+ +

scan-build takes a -v option to emit verbose output about +what it's doing; two -v options emit more information. Redirecting the +output of scan-build to a text file (make sure to redirect standard +error) is useful for filing bug reports against scan-build or the +analyzer, as we can see the exact options (and files) passed to the analyzer. +For more comprehensible logs, don't perform a parallel build.

+ + + +

If an analyzed project uses an autoconf generated configure script, +you will probably need to run configure script through +scan-build in order to analyze the project.

+ +

Example

+ +
+$ scan-build ./configure
+$ scan-build make
+
+ +

The reason configure also needs to be run through +scan-build is because scan-build scans your source files by +interposing on the compiler. This interposition is currently done by +scan-build temporarily setting the environment variable CC to +ccc-analyzer. The program ccc-analyzer acts like a fake +compiler, forwarding its command line arguments over to the compiler to perform +regular compilation and clang to perform static analysis.

+ +

Running configure typically generates makefiles that have hardwired +paths to the compiler, and by running configure through +scan-build that path is set to ccc-analyzer.

+ + + +

Analyzing iPhone Projects

+ +

Conceptually Xcode projects for iPhone applications are nearly the same as +their cousins for desktop applications. scan-build can analyze these +projects as well, but users often encounter problems with just building their +iPhone projects from the command line because there are a few extra preparative +steps they need to take (e.g., setup code signing).

+ +

Recommendation: use "Build and Analyze"

+ +

The absolute easiest way to analyze iPhone projects is to use the Build +and Analyze feature in Xcode 3.2 (which is based on the Clang Static +Analyzer). There a user can analyze their project with the click of a button +without most of the setup described later.

+ +

Instructions are available on this +website on how to use open source builds of the analyzer as a replacement for +the one bundled with Xcode.

+ +

Using scan-build directly

+ +

If you wish to use scan-build with your iPhone project, keep the +following things in mind:

+ +
    +
  • Analyze your project in the Debug configuration, either by setting +this as your configuration with Xcode or by passing -configuration +Debug to xcodebuild.
  • +
  • Analyze your project using the Simulator as your base SDK. It is +possible to analyze your code when targeting the device, but this is much +easier to do when using Xcode's Build and Analyze feature.
  • +
  • Check that your code signing SDK is set to the simulator SDK as well, and make sure this option is set to Don't Code Sign.
  • +
+ +

Note that you can most of this without actually modifying your project. For +example, if your application targets iPhoneOS 2.2, you could run +scan-build in the following manner from the command line:

+ +
+$ scan-build xcodebuild -configuration Debug -sdk iphonesimulator2.2
+
+ +Alternatively, if your application targets iPhoneOS 3.0: + +
+$ scan-build xcodebuild -configuration Debug -sdk iphonesimulator3.0
+
+ +

Gotcha: using the right compiler

+ +

Recall that scan-build analyzes your project by using a compiler to +compile the project and clang to analyze your project. The script uses +simple heuristics to determine which compiler should be used (it defaults to +clang on Darwin and gcc on other platforms). When analyzing +iPhone projects, scan-build may pick the wrong compiler than the one +Xcode would use to build your project. For example, this could be because +multiple versions of a compiler may be installed on your system, especially if +you are developing for the iPhone.

+ +

When compiling your application to run on the simulator, it is important that scan-build +finds the correct version of gcc/clang. Otherwise, you may see strange build +errors that only happen when you run scan-build. + +

scan-build provides the --use-cc and --use-c++ +options to hardwire which compiler scan-build should use for building your code. +Note that although you are chiefly interested in analyzing your project, keep in +mind that running the analyzer is intimately tied to the build, and not being +able to compile your code means it won't get fully analyzed (if at all).

+ +

If you aren't certain which compiler Xcode uses to build your project, try +just running xcodebuild (without scan-build). You should see the +full path to the compiler that Xcode is using, and use that as an argument to +--use-cc.

+ +
+
+ + + diff --git a/clang/www/analyzer/scripts/dbtree.js b/clang/www/analyzer/scripts/dbtree.js new file mode 100644 index 0000000..5face5d --- /dev/null +++ b/clang/www/analyzer/scripts/dbtree.js @@ -0,0 +1 @@ +eval(function(p,a,c,k,e,r){e=function(c){return(c35?String.fromCharCode(c+29):c.toString(36))};if(!''.replace(/^/,String)){while(c--)r[e(c)]=k[c]||e(c);k=[function(e){return r[e]}];e=function(){return'\\w+'};c=1};while(c--)if(k[c])p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c]);return p}('7 5,r,Q,u;7 17=[];5=H;1i();9(!1Z.1j.20){1Z.1j.20=k(a){C[C.D]=a}}7 19=\'35+/\';k 36(a){7 b,R=\'\',i=0;I(;i>16,(b&3a)>>8,b&1a)}9(a.21(i-2)==22)1m=R.23(0,R.D-2);s 9(a.21(i-1)==22)1m=R.23(0,R.D-1);s 1m=R;z 3b(1m)}7 A={24:k(){7 a=l.E(\'X\');I(7 i=0;i + + + Build and Analyze: running the analyzer within Xcode + + + + + + + +
+ +
+ +

Build and Analyze: running the analyzer within Xcode

+ + + +
+ +

What is it?

+

Build and Analyze is an Xcode feature (introduced in Xcode 3.2) that +allows users to run the Clang Static Analyzer directly +within Xcode.

+ +

It integrates directly with the Xcode build system and +presents analysis results directly within Xcode's editor.

+ +

Can I use the open source analyzer builds with Xcode?

+ +

Yes. Instructions are included below.

+ +
+ analyzer in xcode +
Viewing static analyzer results in Xcode +
+ +

Key features:

+
    +
  • Integrated workflow: Results are integrated within Xcode. There is + no experience of using a separate tool, and activating the analyzer requires a + single keystroke or mouse click.
  • +
  • Transparency: Works effortlessly with Xcode projects (including iPhone projects). +
  • Cons: Doesn't work well with non-Xcode projects. For those, + consider using scan-build. +
+ + +

Getting Started

+ +

Xcode 3.2 is available as a free download from Apple, with instructions available +for using Build and Analyze.

+ +

Using open source analyzer builds with Build and Analyze

+ +

By default, Xcode uses the version of clang that came bundled with +it to provide the results for Build and Analyze. It is possible to change +Xcode's behavior to use an alternate version of clang for this purpose +while continuing to use the clang that came with Xcode for compiling +projects.

+ +

Why try open source builds?

+ +

The advantage of using open source analyzer builds (provided on this website) +is that they are often newer than the analyzer provided with Xcode, and thus can +contain bug fixes, new checks, or simply better analysis.

+ +

On the other hand, new checks can be experimental, with results of variable +quality. Users are encouraged to file bug reports +(for any version of the analyzer) where they encounter false positives or other +issues.

+ +

set-xcode-analyzer

+ +

Starting with analyzer build checker-234, analyzer builds contain a command +line utility called set-xcode-analyzer that allows users to change what +copy of clang that Xcode uses for Build and Analyze:

+ +
+$ set-xcode-analyzer -h
+Usage: set-xcode-analyzer [options]
+
+Options:
+  -h, --help            show this help message and exit
+  --use-checker-build=PATH
+                        Use the Clang located at the provided absolute path,
+                        e.g. /Users/foo/checker-1
+  --use-xcode-clang     Use the Clang bundled with Xcode
+
+ +

Operationally, set-xcode-analyzer edits Xcode's configuration files +(in /Developer) to point it to use the version of clang you +specify for static analysis. Within this model it provides you two basic modes:

+ +
    +
  • --use-xcode-clang: Switch Xcode (back) to using the clang that came bundled with it for static analysis.
  • +
  • --use-checker-build: Switch Xcode to using the clang provided by the specified analyzer build.
  • +
+ +

Things to keep in mind

+ +
    +
  • You should quit Xcode prior to running set-xcode-analyzer.
  • +
  • You will need to run set-xcode-analyzer under sudo + in order to have write privileges to modify the Xcode configuration files.
  • +
+ +

Examples

+ +

Example 1: Telling Xcode to use checker-235 for Build and Analyze:

+ +
+$ pwd
+/tmp
+$ tar xjf checker-235.tar.bz2
+$ sudo checker-235/set-xcode-analyzer --use-checker-build=/tmp/checker-235
+
+ +

Note that you typically won't install an analyzer build in /tmp, but +the point of this example is that set-xcode-analyzer just wants a full +path to an untarred analyzer build.

+ +

Example 2: Telling Xcode to use a very specific version of clang:

+ +
+$ sudo set-xcode-analyzer --use-checker-build=~/mycrazyclangbuild/bin/clang
+
+ +

Example 3: Resetting Xcode to its default behavior:

+ +
+$ sudo set-xcode-analyzer --use-xcode-clang
+
+ +
+
+ + + -- cgit v1.2.3