1.1.1.1.core.BitwiseShift (C, C++)¶

Finds undefined behavior caused by the bitwise left- and right-shift operatoroperating on integer types.

By default, this checker only reports situations when the right operand iseither negative or larger than the bit width of the type of the left operand;these are logically unsound.

Moreover, if the pedantic mode is activated by-analyzer-configcore.BitwiseShift:Pedantic=true, then this checker alsoreports situations where the _left_ operand of a shift operator is negative oroverflow occurs during the right shift of a signed value. (Most compilershandle these predictably, but the C standard and the C++ standards before C++20say that they’re undefined behavior. In the C++20 standard these constructs arewell-defined, so activating pedantic mode in C++20 has no effect.)

Examples

static_assert(sizeof(int)==4,"assuming 32-bit int")voidbasic_examples(inta,intb){if(b<0){b=a<<b;// warn: right operand is negative in left shift}elseif(b>=32){b=a>>b;// warn: right shift overflows the capacity of 'int'}}intpedantic_examples(inta,intb){if(a<0){returna>>b;// warn: left operand is negative in right shift}a=1000u<<31;// OK, overflow of unsigned value is well-defined, a == 0if(b>10){a=b<<31;// this is undefined before C++20, but the checker doesn't// warn because it doesn't know the exact value of b}return1000<<31;// warn: this overflows the capacity of 'int'}

Solution

Ensure the shift operands are in proper range before shifting.

1.1.1.2.core.CallAndMessage (C, C++, ObjC)¶

Check for logical errors for function calls and Objective-C message expressions (e.g., uninitialized arguments, null function pointers).

//Cvoidtest(){void(*foo)(void);foo=0;foo();// warn: function pointer is null}// C++classC{public:voidf();};voidtest(){C*pc;pc->f();// warn: object pointer is uninitialized}// C++classC{public:voidf();};voidtest(){C*pc=0;pc->f();// warn: object pointer is null}// Objective-C@interfaceMyClass :NSObject@property(readwrite,assign)idx;-(longdouble)longDoubleM;@endvoidtest(){MyClass*obj1;longdoubleld1=[obj1longDoubleM];// warn: receiver is uninitialized}// Objective-C@interfaceMyClass :NSObject@property(readwrite,assign)idx;-(longdouble)longDoubleM;@endvoidtest(){MyClass*obj1;idi=obj1.x;// warn: uninitialized object pointer}// Objective-C@interfaceSubscriptable :NSObject-(id)objectAtIndexedSubscript:(unsignedint)index;@end@interfaceMyClass :Subscriptable@property(readwrite,assign)idx;-(longdouble)longDoubleM;@endvoidtest(){MyClass*obj1;idi=obj1[0];// warn: uninitialized object pointer}

1.1.1.3.core.DivideZero (C, C++, ObjC)¶

Check for division by zero.

voidtest(intz){if(z==0)intx=1/z;// warn}voidtest(){intx=1;inty=x%0;// warn}

1.1.1.4.core.FixedAddressDereference (C, C++, ObjC)¶

Check for dereferences of fixed addresses.

A pointer contains a fixed address if it was set to a hard-coded value or itbecomes otherwise obvious that at that point it can have only a single fixednumerical value.

voidtest1(){int*p=(int*)0x020;intx=p[0];// warn}voidtest2(int*p){if(p==(int*)-1)*p=0;// warn}voidtest3(){int(*p_function)(char,char);p_function=(int(*)(char,char))0x04080;intx=(*p_function)('x','y');// NO warning yet at functon pointer calls}

If the analyzer optionsuppress-dereferences-from-any-address-space is setto true (the default value), then this checker never reports dereference ofpointers with a specified address space. If the option is set to false, thenreports from the specific x86 address spaces 256, 257 and 258 are stillsuppressed, but fixed address dereferences from other address spaces arereported.

1.1.1.5.core.NonNullParamChecker (C, C++, ObjC)¶

Check for null pointers passed as arguments to a function whose arguments are references or marked with the ‘nonnull’ attribute.

intf(int*p)__attribute__((nonnull));voidtest(int*p){if(!p)f(p);// warn}

1.1.1.6.core.NullDereference (C, C++, ObjC)¶

Check for dereferences of null pointers.

// Cvoidtest(int*p){if(p)return;intx=p[0];// warn}// Cvoidtest(int*p){if(!p)*p=0;// warn}// C++classC{public:intx;};voidtest(){C*pc=0;intk=pc->x;// warn}// Objective-C@interfaceMyClass{@publicintx;}@endvoidtest(){MyClass*obj=0;obj->x=1;// warn}

Null pointer dereferences of pointers with address spaces are not always definedas error. Specifically on x86/x86-64 target if the pointer address space is256 (x86 GS Segment), 257 (x86 FS Segment), or 258 (x86 SS Segment), a nulldereference is not defined as error. SeeX86/X86-64 Language Extensionsfor reference.

If the analyzer optionsuppress-dereferences-from-any-address-space is setto true (the default value), then this checker never reports dereference ofpointers with a specified address space. If the option is set to false, thenreports from the specific x86 address spaces 256, 257 and 258 are stillsuppressed, but null dereferences from other address spaces are reported.

1.1.1.7.core.NullPointerArithm (C, C++)¶

Check for undefined arithmetic operations with null pointers.

The checker can detect the following cases:

• p+x andx+p wherep is a null pointer andx is a nonzerointeger value.

• p-x wherep is a null pointer andx is a nonzero integervalue.

• p1-p2 where one ofp1 andp2 is null and the other anon-null pointer.

Result of these operations is undefined according to the standard.In the above listed cases, the checker will warn even if the expressiondescribed to be “nonzero” or “non-null” has unknown value, because it is likelythat it can have non-zero value during the program execution.

voidtest1(int*p,intoffset){if(p)return;int*p1=p+offset;// warn: 'p' is null, 'offset' is unknown but likely non-zero}voidtest2(int*p,intoffset){if(p){}// this indicates that it is possible for 'p' to be nullif(offset==0)return;int*p1=p-offset;// warn: 'p' is null, 'offset' is known to be non-zero}voidtest3(char*p1,char*p2){if(p1)return;inta=p1-p2;// warn: 'p1' is null, 'p2' can be likely non-null}

1.1.1.8.core.StackAddressEscape (C)¶

Check that addresses to stack memory do not escape the function.

charconst*p;voidtest(){charconststr[]="string";p=str;// warn}void*test(){return__builtin_alloca(12);// warn}voidtest(){staticint*x;inty;x=&y;// warn}

1.1.1.9.core.UndefinedBinaryOperatorResult (C)¶

Check for undefined results of binary operators.

voidtest(){intx;inty=x+1;// warn: left operand is garbage}

1.1.1.10.core.VLASize (C)¶

Check for declarations of Variable Length Arrays (VLA) of undefined, zero or negativesize.

voidtest(){intx;intvla1[x];// warn: garbage as size}voidtest(){intx=0;intvla2[x];// warn: zero size}

The checker also gives warning if theTaintPropagation checker is switched onand an unbound, attacker controlled (tainted) value is used to definethe size of the VLA.

voidtaintedVLA(void){intx;scanf("%d",&x);intvla[x];// Declared variable-length array (VLA) has tainted (attacker controlled) size, that can be 0 or negative}voidtaintedVerfieidVLA(void){intx;scanf("%d",&x);if(x<1)return;intvla[x];// no-warning. The analyzer can prove that x must be positive.}

1.1.1.11.core.uninitialized.ArraySubscript (C)¶

Check for uninitialized values used as array subscripts.

voidtest(){inti,a[10];intx=a[i];// warn: array subscript is undefined}

1.1.1.12.core.uninitialized.Assign (C)¶

Check for assigning uninitialized values.

voidtest(){intx;x|=1;// warn: left expression is uninitialized}

1.1.1.13.core.uninitialized.Branch (C)¶

Check for uninitialized values used as branch conditions.

voidtest(){intx;if(x)// warnreturn;}

1.1.1.14.core.uninitialized.CapturedBlockVariable (C)¶

Check for blocks that capture uninitialized values.

voidtest(){intx;^{inty=x;}();// warn}

1.1.1.15.core.uninitialized.UndefReturn (C)¶

Check for uninitialized values being returned to the caller.

inttest(){intx;returnx;// warn}

1.1.1.16.core.uninitialized.NewArraySize (C++)¶

Check if the element count in new[] is garbage or undefined.

voidtest(){intn;int*arr=newint[n];// warn: Element count in new[] is a garbage valuedelete[]arr;}

1.1.2.1.cplusplus.ArrayDelete (C++)¶

Reports destructions of arrays of polymorphic objects that are destructed astheir base class. If the dynamic type of the array is different from its statictype, callingdelete[] is undefined.

This checker corresponds to the SEI CERT ruleEXP51-CPP: Do not delete an array through a pointer of the incorrect type.

classBase{public:virtual~Base(){}};classDerived:publicBase{};Base*create(){Base*x=newDerived[10];// note: Casting from 'Derived' to 'Base' herereturnx;}voidfoo(){Base*x=create();delete[]x;// warn: Deleting an array of 'Derived' objects as their base class 'Base' is undefined}

Limitations

The checker does not emit note tags when casting to and from reference types,even though the pointer values are tracked across references.

voidfoo(){Derived*d=newDerived[10];Derived&dref=*d;Base&bref=static_cast<Base&>(dref);// no noteBase*b=&bref;delete[]b;// warn: Deleting an array of 'Derived' objects as their base class 'Base' is undefined}

1.1.2.2.cplusplus.InnerPointer (C++)¶

Check for inner pointers of C++ containers used after re/deallocation.

Many container methods in the C++ standard library are known to invalidate“references” (including actual references, iterators and raw pointers) toelements of the container. Using such references after they are invalidatedcauses undefined behavior, which is a common source of memory errors in C++ thatthis checker is capable of finding.

The checker is currently limited tostd::string objects and doesn’trecognize some of the more sophisticated approaches to passing unowned pointersaround, such asstd::string_view.

voidderef_after_assignment(){std::strings="llvm";constchar*c=s.data();// note: pointer to inner buffer of 'std::string' obtained heres="clang";// note: inner buffer of 'std::string' reallocated by call to 'operator='consume(c);// warn: inner pointer of container used after re/deallocation}constchar*return_temp(intx){returnstd::to_string(x).c_str();// warn: inner pointer of container used after re/deallocation// note: pointer to inner buffer of 'std::string' obtained here// note: inner buffer of 'std::string' deallocated by call to destructor}

1.1.2.3.cplusplus.Move (C++)¶

Find use-after-move bugs in C++. This includes method calls on moved-fromobjects, assignment of a moved-from object, and repeated move of a moved-fromobject.

structA{voidfoo(){}};voidf1(){Aa;Ab=std::move(a);// note: 'a' became 'moved-from' herea.foo();// warn: method call on a 'moved-from' object 'a'}voidf2(){Aa;Ab=std::move(a);Ac(std::move(a));// warn: move of an already moved-from object}voidf3(){Aa;Ab=std::move(a);b=a;// warn: copy of moved-from object}

The checker optionWarnOn controls on what objects the use-after-move ischecked:

• The most strict value isKnownsOnly, in this mode only objects arechecked whose type is known to be move-unsafe. These include most STL objects(but excluding move-safe ones) and smart pointers.

• With option valueKnownsAndLocals local variables (of any type) areadditionally checked. The idea behind this is that local variables areusually not tempting to be re-used so an use after move is more likely a bugthan with member variables.

• With option valueAll any use-after move condition is checked on allkinds of variables, excluding global variables and known move-safe cases.

Default value isKnownsAndLocals.

Calls of methods namedempty() orisEmpty() are allowed on moved-fromobjects because these methods are considered as move-safe. Functions calledreset(),destroy(),clear(),assign,resize,shrink aretreated as state-reset functions and are allowed on moved-from objects, thesemake the object valid again. This applies to any type of object (not only STLones).

1.1.2.4.cplusplus.NewDelete (C++)¶

Check for double-free and use-after-free problems. Traces memory managed by new/delete.

Custom allocation/deallocation functions can be defined usingownership attributes.

voidf(int*p);voidtestUseMiddleArgAfterDelete(int*p){deletep;f(p);// warn: use after free}classSomeClass{public:voidf();};voidtest(){SomeClass*c=newSomeClass;deletec;c->f();// warn: use after free}voidtest(){int*p=(int*)__builtin_alloca(sizeof(int));deletep;// warn: deleting memory allocated by alloca}voidtest(){int*p=newint;deletep;deletep;// warn: attempt to free released}voidtest(){inti;delete&i;// warn: delete address of local}voidtest(){int*p=newint[1];delete[](++p);// warn: argument to 'delete[]' is offset by 4 bytes// from the start of memory allocated by 'new[]'}

1.1.2.5.cplusplus.NewDeleteLeaks (C++)¶

Check for memory leaks. Traces memory managed by new/delete.

Custom allocation/deallocation functions can be defined usingownership attributes.

voidtest(){int*p=newint;}// warn

1.1.2.6.cplusplus.PlacementNew (C++)¶

Check if default placement new is provided with pointers to sufficient storage capacity.

#include<new>voidf(){shorts;long*lp=::new(&s)long;// warn}

1.1.2.7.cplusplus.SelfAssignment (C++)¶

Checks C++ copy and move assignment operators for self assignment.

1.1.2.8.cplusplus.StringChecker (C++)¶

Checks std::string operations.

Checks if the cstring pointer from which thestd::string object isconstructed isNULL or not.If the checker cannot reason about the nullness of the pointer it will assumethat it was non-null to satisfy the precondition of the constructor.

This checker is capable of checking theSEI CERT C++ coding rule STR51-CPP.Do not attempt to create a std::string from a null pointer.

#include<string>voidf(constchar*p){if(!p){std::stringmsg(p);// warn: The parameter must not be null}}

1.1.2.9.cplusplus.PureVirtualCall (C++)¶

Whenvirtual methods are called during construction and destructionthe polymorphism is restricted to the class that’s being constructed ordestructed because the more derived contexts are either not yet initialized oralready destructed.

This checker reports situations where this restricted polymorphism causes acall to a pure virtual method, which is undefined behavior. (See also therelated checkeroptin.cplusplus.VirtualCall (C++) which reports situationswhere the restricted polymorphism affects a call and the called method is notpure virtual – but may be still surprising for the programmer.)

structA{virtualintgetKind()=0;A(){// warn: This calls the pure virtual method A::getKind().log<<"Constructing "<<getKind();}virtual~A(){releaseResources();}voidreleaseResources(){// warn: This can call the pure virtual method A::getKind() when this is// called from the destructor.callSomeFunction(getKind());}};

1.1.3.1.deadcode.DeadStores (C)¶

Check for values stored to variables that are never read afterwards.

voidtest(){intx;x=1;// warn}

TheWarnForDeadNestedAssignments option enables the checker to emitwarnings for nested dead assignments. You can disable with the-analyzer-configdeadcode.DeadStores:WarnForDeadNestedAssignments=false.Defaults to true.

Would warn for this e.g.:if ((y = make_int())) {}

1.1.4.1.nullability.NullPassedToNonnull (ObjC)¶

Warns when a null pointer is passed to a pointer which has a _Nonnull type.

if(name!=nil)return;// Warning: nil passed to a callee that requires a non-null 1st parameterNSString*greeting=[@"Hello "stringByAppendingString:name];

1.1.4.2.nullability.NullReturnedFromNonnull (C, C++, ObjC)¶

Warns when a null pointer is returned from a function that has _Nonnull return type.

-(nonnullid)firstChild{idresult=nil;if([_childrencount]>0)result=_children[0];// Warning: nil returned from a method that is expected// to return a non-null valuereturnresult;}

Warns when a null pointer is returned from a function annotated with__attribute__((returns_nonnull))

intglobal;__attribute__((returns_nonnull))void*getPtr(void*p);void*getPtr(void*p){if(p){// forgot to negate the conditionreturn&global;}// Warning: nullptr returned from a function that is expected// to return a non-null valuereturnp;}

1.1.4.3.nullability.NullableDereferenced (ObjC)¶

Warns when a nullable pointer is dereferenced.

structLinkedList{intdata;structLinkedList*next;};structLinkedList*_NullablegetNext(structLinkedList*l);voidupdateNextData(structLinkedList*list,intnewData){structLinkedList*next=getNext(list);// Warning: Nullable pointer is dereferencednext->data=7;}

1.1.4.4.nullability.NullablePassedToNonnull (ObjC)¶

Warns when a nullable pointer is passed to a pointer which has a _Nonnull type.

typedefstructDummy{intval;}Dummy;Dummy*_NullablereturnsNullable();voidtakesNonnull(Dummy*_Nonnull);voidtest(){Dummy*p=returnsNullable();takesNonnull(p);// warn}

1.1.4.5.nullability.NullableReturnedFromNonnull (ObjC)¶

Warns when a nullable pointer is returned from a function that has _Nonnull return type.

1.1.5.1.optin.core.EnumCastOutOfRange (C, C++)¶

Check for integer to enumeration casts that would produce a value with nocorresponding enumerator. This is not necessarily undefined behavior, but canlead to nasty surprises, so projects may decide to use a coding standard thatdisallows these “unusual” conversions.

Note that no warnings are produced when the enum type (e.g.std::byte) has noenumerators at all.

enumWidgetKind{A=1,B,C,X=99};voidfoo(){WidgetKindc=static_cast<WidgetKind>(3);// OKWidgetKindx=static_cast<WidgetKind>(99);// OKWidgetKindd=static_cast<WidgetKind>(4);// warn}

Limitations

This checker does not accept the coding pattern where an enum type is used tostore combinations of flag values.Such enums should be annotated with the__attribute__((flag_enum)) or by the[[clang::flag_enum]] attribute to signal this intent. Refer to thedocumentationof this Clang attribute.

enumAnimalFlags{HasClaws=1,CanFly=2,EatsFish=4,Endangered=8};AnimalFlagsoperator|(AnimalFlagsa,AnimalFlagsb){returnstatic_cast<AnimalFlags>(static_cast<int>(a)|static_cast<int>(b));}autoflags=HasClaws|CanFly;

Projects that use this pattern should not enable this optin checker.

1.1.5.2.optin.cplusplus.UninitializedObject (C++)¶

This checker reports uninitialized fields in objects created after a constructorcall. It doesn’t only find direct uninitialized fields, but rather makes a deepinspection of the object, analyzing all of its fields’ subfields.The checker regards inherited fields as direct fields, so one will receivewarnings for uninitialized inherited data members as well.

// With Pedantic and CheckPointeeInitialization set to truestructA{structB{intx;// note: uninitialized field 'this->b.x'// note: uninitialized field 'this->bptr->x'inty;// note: uninitialized field 'this->b.y'// note: uninitialized field 'this->bptr->y'};int*iptr;// note: uninitialized pointer 'this->iptr'Bb;B*bptr;char*cptr;// note: uninitialized pointee 'this->cptr'A(B*bptr,char*cptr):bptr(bptr),cptr(cptr){}};voidf(){A::Bb;charc;Aa(&b,&c);// warning: 6 uninitialized fields//          after the constructor call}// With Pedantic set to false and// CheckPointeeInitialization set to true// (every field is uninitialized)structA{structB{intx;inty;};int*iptr;Bb;B*bptr;char*cptr;A(B*bptr,char*cptr):bptr(bptr),cptr(cptr){}};voidf(){A::Bb;charc;Aa(&b,&c);// no warning}// With Pedantic set to true and// CheckPointeeInitialization set to false// (pointees are regarded as initialized)structA{structB{intx;// note: uninitialized field 'this->b.x'inty;// note: uninitialized field 'this->b.y'};int*iptr;// note: uninitialized pointer 'this->iptr'Bb;B*bptr;char*cptr;A(B*bptr,char*cptr):bptr(bptr),cptr(cptr){}};voidf(){A::Bb;charc;Aa(&b,&c);// warning: 3 uninitialized fields//          after the constructor call}

Options

This checker has several options which can be set from command line (e.g.-analyzer-configoptin.cplusplus.UninitializedObject:Pedantic=true):

• Pedantic (boolean). If to false, the checker won’t emit warnings forobjects that don’t have at least one initialized field. Defaults to false.

• NotesAsWarnings (boolean). If set to true, the checker will emit awarning for each uninitialized field, as opposed to emitting one warning perconstructor call, and listing the uninitialized fields that belongs to it innotes.Defaults to false.

• CheckPointeeInitialization (boolean). If set to false, the checker willnot analyze the pointee of pointer/reference fields, and will only checkwhether the object itself is initialized.Defaults to false.

• IgnoreRecordsWithField (string). If supplied, the checker will not analyzestructures that have a field with a name or type name that matches the givenpattern.Defaults to “”.

1.1.5.3.optin.cplusplus.VirtualCall (C++)¶

Whenvirtual methods are called during construction and destructionthe polymorphism is restricted to the class that’s being constructed ordestructed because the more derived contexts are either not yet initialized oralready destructed.

Although this behavior is well-defined, it can surprise the programmer andcause unintended behavior, so this checker reports calls that appear to bevirtual calls but can be affected by this restricted polymorphism.

Note that situations where this restricted polymorphism causes a call to a purevirtual method (which is definitely invalid, triggers undefined behavior) arereported by another checker:cplusplus.PureVirtualCall (C++) andthischecker does not report them.

structA{virtualintgetKind();A(){// warn: This calls A::getKind() even if we are constructing an instance// of a different class that is derived from A.log<<"Constructing "<<getKind();}virtual~A(){releaseResources();}voidreleaseResources(){// warn: This can be called within ~A() and calls A::getKind() even if// we are destructing a class that is derived from A.callSomeFunction(getKind());}};

1.1.5.4.optin.mpi.MPI-Checker (C)¶

Checks MPI code.

voidtest(){doublebuf=0;MPI_RequestsendReq1;MPI_Ireduce(MPI_IN_PLACE,&buf,1,MPI_DOUBLE,MPI_SUM,0,MPI_COMM_WORLD,&sendReq1);}// warn: request 'sendReq1' has no matching wait.voidtest(){doublebuf=0;MPI_RequestsendReq;MPI_Isend(&buf,1,MPI_DOUBLE,0,0,MPI_COMM_WORLD,&sendReq);MPI_Irecv(&buf,1,MPI_DOUBLE,0,0,MPI_COMM_WORLD,&sendReq);// warnMPI_Isend(&buf,1,MPI_DOUBLE,0,0,MPI_COMM_WORLD,&sendReq);// warnMPI_Wait(&sendReq,MPI_STATUS_IGNORE);}voidmissingNonBlocking(){intrank=0;MPI_Comm_rank(MPI_COMM_WORLD,&rank);MPI_RequestsendReq1[10][10][10];MPI_Wait(&sendReq1[1][7][9],MPI_STATUS_IGNORE);// warn}

1.1.5.5.optin.osx.cocoa.localizability.EmptyLocalizationContextChecker (ObjC)¶

Check that NSLocalizedString macros include a comment for context.

-(void)test{NSString*string=NSLocalizedString(@"LocalizedString",nil);// warnNSString*string2=NSLocalizedString(@"LocalizedString",@" ");// warnNSString*string3=NSLocalizedStringWithDefaultValue(@"LocalizedString",nil,[[NSBundlealloc]init],nil,@"");// warn}

1.1.5.6.optin.osx.cocoa.localizability.NonLocalizedStringChecker (ObjC)¶

Warns about uses of non-localized NSStrings passed to UI methods expecting localized NSStrings.

NSString*alarmText=NSLocalizedString(@"Enabled",@"Indicates alarm is turned on");if(!isEnabled){alarmText=@"Disabled";}UILabel*alarmStateLabel=[[UILabelalloc]init];// Warning: User-facing text should use localized string macro[alarmStateLabelsetText:alarmText];

1.1.5.7.optin.performance.GCDAntipattern¶

Check for performance anti-patterns when using Grand Central Dispatch.

1.1.5.8.optin.performance.Padding (C, C++, ObjC)¶

Check for excessively padded structs.

This checker detects structs with excessive padding, which can lead to wastedmemory thus decreased performance by reducing the effectiveness of theprocessor cache. Padding bytes are added by compilers to align data accessesas some processors require data to be aligned to certain boundaries. On others,unaligned data access are possible, but impose significantly larger latencies.

To avoid padding bytes, the fields of a struct should be ordered by decreasingby alignment. Usually, its easier to think of thesizeof of the fields, andordering the fields bysizeof would usually also lead to the same optimallayout.

In rare cases, one can use the#pragmapack(1) directive to enforce a packedlayout too, but it can significantly increase the access times, so reordering thefields is usually a better solution.

// warn: Excessive padding in 'struct NonOptimal' (35 padding bytes, where 3 is optimal)structNonOptimal{charc1;// 7 bytes of paddingstd::int64_tbig1;// 8 bytescharc2;// 7 bytes of paddingstd::int64_tbig2;// 8 bytescharc3;// 7 bytes of paddingstd::int64_tbig3;// 8 bytescharc4;// 7 bytes of paddingstd::int64_tbig4;// 8 bytescharc5;// 7 bytes of padding};static_assert(sizeof(NonOptimal)==4*8+5+5*7);// no-warning: The fields are nicely aligned to have the minimal amount of padding bytes.structOptimal{std::int64_tbig1;// 8 bytesstd::int64_tbig2;// 8 bytesstd::int64_tbig3;// 8 bytesstd::int64_tbig4;// 8 bytescharc1;charc2;charc3;charc4;charc5;// 3 bytes of padding};static_assert(sizeof(Optimal)==4*8+5+3);// no-warning: Bit packing representation is also accepted by this checker, but// it can significantly increase access times, so prefer reordering the fields.#pragma pack(1)structBitPacked{charc1;std::int64_tbig1;// 8 bytescharc2;std::int64_tbig2;// 8 bytescharc3;std::int64_tbig3;// 8 bytescharc4;std::int64_tbig4;// 8 bytescharc5;};static_assert(sizeof(BitPacked)==4*8+5);

TheAllowedPad option can be used to specify a threshold for the numberpadding bytes raising the warning. If the number of padding bytes of the structand the optimal number of padding bytes differ by more than the threshold value,a warning will be raised.

By default, theAllowedPad threshold is 24 bytes.

To override this threshold to e.g. 4 bytes, use the-analyzer-configoptin.performance.Padding:AllowedPad=4 option.

1.1.5.9.optin.portability.UnixAPI¶

Reports situations where 0 is passed as the “size” argument of variousallocation functions (calloc,malloc,realloc,reallocf,alloca,__builtin_alloca,__builtin_alloca_with_align,valloc).

Note that similar functionality is also supported byunix.Malloc (C) whichreports code thatuses memory allocated with size zero.

(The name of this checker is motivated by the fact that it was originallyintroduced with the vague goal that it “Finds implementation-defined behaviorin UNIX/Posix functions.”)

1.1.6.1.optin.taint.GenericTaint (C, C++)¶

Taint analysis identifies potential security vulnerabilities where theattacker can inject malicious data to the program to execute an attack(privilege escalation, command injection, SQL injection etc.).

The malicious data is injected at the taint source (e.g.getenv() call)which is then propagated through function calls and being used as arguments ofsensitive operations, also called as taint sinks (e.g.system() call).

One can defend against this type of vulnerability by always checking andsanitizing the potentially malicious, untrusted user input.

The goal of the checker is to discover and show to the user these potentialtaint source-sink pairs and the propagation call chain.

The most notable examples of taint sources are:

• data from network

• files or standard input

• environment variables

• data from databases

Let us examine a practical example of a Command Injection attack.

// Command Injection Vulnerability Exampleintmain(intargc,char**argv){charcmd[2048]="/bin/cat ";charfilename[1024];printf("Filename:");scanf(" %1023[^\n]",filename);// The attacker can inject a shell escape herestrcat(cmd,filename);system(cmd);// Warning: Untrusted data is passed to a system call}

The program prints the content of any user specified file.Unfortunately the attacker can execute arbitrary commandswith shell escapes. For example with the following input thels command is alsoexecuted after the contents of/etc/shadow is printed.Input: /etc/shadow ; ls /

The analysis implemented in this checker points out this problem.

One can protect against such attack by for example checking if the providedinput refers to a valid file and removing any invalid user input.

// No vulnerability anymore, but we still get the warningvoidsanitizeFileName(char*filename){if(access(filename,F_OK)){// Verifying user inputprintf("File does not exist\n");filename[0]='\0';}}intmain(intargc,char**argv){charcmd[2048]="/bin/cat ";charfilename[1024];printf("Filename:");scanf(" %1023[^\n]",filename);// The attacker can inject a shell escape heresanitizeFileName(filename);// filename is safe after this pointif(!filename[0])return-1;strcat(cmd,filename);system(cmd);// Superfluous Warning: Untrusted data is passed to a system call}

Unfortunately, the checker cannot discover automatically that the programmerhave performed data sanitation, so it still emits the warning.

One can get rid of this superfluous warning by telling by specifying thesanitation functions in the taint configuration file (seeTaint Analysis Configuration).

Filters:-Name:sanitizeFileNameArgs:[0]

The clang invocation to pass the configuration file location:

clang--analyze-Xclang-analyzer-config-Xclangoptin.taint.TaintPropagation:Config=`pwd`/taint_config.yml...

If you are validating your inputs instead of sanitizing them, or don’t want tomention each sanitizing function in our configuration,you can use a more generic approach.

Introduce a generic no-opcsa_mark_sanitized(..) function totell the Clang Static Analyzerthat the variable is safe to be used on that analysis path.

// Marking sanitized variables safe.// No vulnerability anymore, no warning.// User csa_mark_sanitize function is for the analyzer only#ifdef __clang_analyzer__voidcsa_mark_sanitized(constvoid*);#endifintmain(intargc,char**argv){charcmd[2048]="/bin/cat ";charfilename[1024];printf("Filename:");scanf(" %1023[^\n]",filename);if(access(filename,F_OK)){// Verifying user inputprintf("File does not exist\n");return-1;}#ifdef __clang_analyzer__csa_mark_sanitized(filename);// Indicating to CSA that filename variable is safe to be used after this point#endifstrcat(cmd,filename);system(cmd);// No warning}

Similarly to the previous example, you need todefine aFilter function in aYAML configuration fileand add thecsa_mark_sanitized function.

Filters:-Name:csa_mark_sanitizedArgs:[0]

Then callingcsa_mark_sanitized(X) will tell the analyzer thatX is safe tobe used after this point, because its contents are verified. It is theresponsibility of the programmer to ensure that this verification was indeedcorrect. Please note thatcsa_mark_sanitized function is only declared andused during Clang Static Analysis and skipped in (production) builds.

Further examples of injection vulnerabilities this checker can find.

voidtest(){charx=getchar();// 'x' marked as taintedsystem(&x);// warn: untrusted data is passed to a system call}// note: compiler internally checks if the second param to// sprintf is a string literal or not.// Use -Wno-format-security to suppress compiler warning.voidtest(){chars[10],buf[10];fscanf(stdin,"%s",s);// 's' marked as taintedsprintf(buf,s);// warn: untrusted data used as a format string}

There are built-in sources, propagations and sinks even if no external taintconfiguration is provided.

Default sources:

_IO_getc,fdopen,fopen,freopen,get_current_dir_name,getch,getchar,getchar_unlocked,getwd,getcwd,getgroups,gethostname,getlogin,getlogin_r,getnameinfo,gets,gets_s,getseuserbyname,readlink,readlinkat,scanf,scanf_s,socket,wgetch

Default propagations rules:

atoi,atol,atoll,basename,dirname,fgetc,fgetln,fgets,fnmatch,fread,fscanf,fscanf_s,index,inflate,isalnum,isalpha,isascii,isblank,iscntrl,isdigit,isgraph,islower,isprint,ispunct,isspace,isupper,isxdigit,memchr,memrchr,sscanf,getc,getc_unlocked,getdelim,getline,getw,memcmp,memcpy,memmem,memmove,mbtowc,pread,qsort,qsort_r,rawmemchr,read,recv,recvfrom,rindex,strcasestr,strchr,strchrnul,strcasecmp,strcmp,strcspn,strncasecmp,strncmp,strndup,strndupa,strpbrk,strrchr,strsep,strspn,strstr,strtol,strtoll,strtoul,strtoull,tolower,toupper,ttyname,ttyname_r,wctomb,wcwidth

Default sinks:

printf,setproctitle,system,popen,execl,execle,execlp,execv,execvp,execvP,execve,dlopen

Please note that there are no built-in filter functions.

One can configure their own taint sources, sinks, and propagation rules byproviding a configuration file via checker optionoptin.taint.TaintPropagation:Config. The configuration file is inYAML format. Thetaint-related options defined in the config file extend but do not override thebuilt-in sources, rules, sinks. The format of the external taint configurationfile is not stable, and could change without any notice even in a non-backwardcompatible way.

For a more detailed description of configuration options, please see theTaint Analysis Configuration. For an example seeExample configuration file.

Configuration

• Config Specifies the name of the YAML configuration file. The user candefine their own taint sources and sinks.

Related Guidelines

• CWE Data Neutralization Issues

• SEI Cert STR02-C. Sanitize data passed to complex subsystems

• SEI Cert ENV33-C. Do not call system()

• ENV03-C. Sanitize the environment when invoking external programs

Limitations

• The taintedness property is not propagated through function calls which areunknown (or too complex) to the analyzer, unless there is a specificpropagation rule built-in to the checker or given in the YAML configurationfile. This causes potential true positive findings to be lost.

1.1.6.2.optin.taint.TaintedAlloc (C, C++)¶

This checker warns for cases when thesize parameter of themalloc ,calloc,realloc,alloca or the size parameter of thearray new C++ operator is tainted (potentially attacker controlled).If an attacker can inject a large value as the size parameter, memory exhaustiondenial of service attack can be carried out.

The analyzer emits warning only if it cannot prove that the size parameter iswithin reasonable bounds (<=SIZE_MAX/4). This functionality partiallycovers the SEI Cert coding standard ruleINT04-C.

You can silence this warning either by bound checking thesize parameter, orby explicitly marking thesize parameter as sanitized. See theoptin.taint.GenericTaint (C, C++) checker for an example.

Custom allocation/deallocation functions can be defined usingownership attributes.

voidvulnerable(void){size_tsize=0;scanf("%zu",&size);int*p=malloc(size);// warn: malloc is called with a tainted (potentially attacker controlled) valuefree(p);}voidnot_vulnerable(void){size_tsize=0;scanf("%zu",&size);if(1024<size)return;int*p=malloc(size);// No warning expected as the the user input is boundfree(p);}voidvulnerable_cpp(void){size_tsize=0;scanf("%zu",&size);int*ptr=newint[size];// warn: Memory allocation function is called with a tainted (potentially attacker controlled) valuedelete[]ptr;}

1.1.6.3.optin.taint.TaintedDiv (C, C++, ObjC)¶

This checker warns when the denominator in a divisionoperation is a tainted (potentially attacker controlled) value.If the attacker can set the denominator to 0, a runtime error canbe triggered. The checker warns when the denominator is a taintedvalue and the analyzer cannot prove that it is not 0. This warningis more pessimistic than thecore.DivideZero (C, C++, ObjC) checkerwhich warns only when it can prove that the denominator is 0.

intvulnerable(intn){size_tsize=0;scanf("%zu",&size);returnn/size;// warn: Division by a tainted value, possibly zero}intnot_vulnerable(intn){size_tsize=0;scanf("%zu",&size);if(!size)return0;returnn/size;// no warning}

1.1.7.1.security.ArrayBound (C, C++)¶

Report out of bounds access to memory that is before the start or after the endof the accessed region (array, heap-allocated region, string literal etc.).This usually means incorrect indexing, but the checker also detects access viathe operators* and->.

voidtest_underflow(intx){intbuf[100][100];if(x<0)buf[0][x]=1;// warn}voidtest_overflow(){intbuf[100];int*p=buf+100;*p=1;// warn}

If checkers likeunix.Malloc (C) orcplusplus.NewDelete (C++) are enabledto model the behavior ofmalloc(),operatornew and similarallocators), then this checker can also reports out of bounds access todynamically allocated memory:

int*test_dynamic(){int*mem=newint[100];mem[-1]=42;// warnreturnmem;}

In uncertain situations (when the checker can neither prove nor disprove thatoverflow occurs), the checker assumes that the the index (more precisely, thememory offeset) is within bounds.

However, ifoptin.taint.GenericTaint (C, C++) is enabled and the index/offset istainted (i.e. it is influenced by an untrusted source), then this checkerreports the potential out of bounds access:

voidtest_with_tainted_index(){chars[]="abc";intx=getchar();charc=s[x];// warn: potential out of bounds access with tainted index}

1.1.7.2.security.cert.env.InvalidPtr¶

Corresponds to SEI CERT RulesENV31-C andENV34-C.

• ENV31-C:Rule is about the possible problem withmain function’s third argument, environment pointer,“envp”. When environment array is modified using some modification functionsuch asputenv,setenv or others, It may happen that memory is reallocated,however “envp” is not updated to reflect the changes and points to old memoryregion.

• ENV34-C:Some functions return a pointer to a statically allocated buffer.Consequently, subsequent call of these functions will invalidate previouspointer. These functions include:getenv,localeconv,asctime,setlocale,strerror

intmain(intargc,constchar*argv[],constchar*envp[]){if(setenv("MY_NEW_VAR","new_value",1)!=0){// setenv call may invalidate 'envp'/* Handle error */}if(envp!=NULL){for(size_ti=0;envp[i]!=NULL;++i){puts(envp[i]);// envp may no longer point to the current environment// this program has unanticipated behavior, since envp// does not reflect changes made by setenv function.}}return0;}voidprevious_call_invalidation(){char*p,*pp;p=getenv("VAR");setenv("SOMEVAR","VALUE",/*overwrite = */1);// call to 'setenv' may invalidate p*p;// dereferencing invalid pointer}

TheInvalidatingGetEnv option is available for treatinggetenv calls asinvalidating. When enabled, the checker issues a warning ifgetenv is calledmultiple times and their results are used without first creating a copy.This level of strictness might be considered overly pedantic for the commonlyusedgetenv implementations.

To enable this option, use:-analyzer-configsecurity.cert.env.InvalidPtr:InvalidatingGetEnv=true.

By default, this option is set tofalse.

When this option is enabled, warnings will be generated for scenarios like thefollowing:

char*p=getenv("VAR");char*pp=getenv("VAR2");// assumes this call can invalidate `env`strlen(p);// warns about accessing invalid ptr

1.1.7.3.security.FloatLoopCounter (C)¶

Warn on using a floating point value as a loop counter (CERT: FLP30-C, FLP30-CPP).

voidtest(){for(floatx=0.1f;x<=1.0f;x+=0.1f){}// warn}

1.1.7.4.security.insecureAPI.UncheckedReturn (C)¶

Warn on uses of functions whose return values must be always checked.

voidtest(){setuid(1);// warn}

1.1.7.5.security.insecureAPI.bcmp (C)¶

Warn on uses of the ‘bcmp’ function.

voidtest(){bcmp(ptr0,ptr1,n);// warn}

1.1.7.6.security.insecureAPI.bcopy (C)¶

Warn on uses of the ‘bcopy’ function.

voidtest(){bcopy(src,dst,n);// warn}

1.1.7.7.security.insecureAPI.bzero (C)¶

Warn on uses of the ‘bzero’ function.

voidtest(){bzero(ptr,n);// warn}

1.1.7.8.security.insecureAPI.getpw (C)¶

Warn on uses of the ‘getpw’ function.

voidtest(){charbuff[1024];getpw(2,buff);// warn}

1.1.7.9.security.insecureAPI.gets (C)¶

Warn on uses of the ‘gets’ function.

voidtest(){charbuff[1024];gets(buff);// warn}

1.1.7.10.security.insecureAPI.mkstemp (C)¶

Warn when ‘mkstemp’ is passed fewer than 6 X’s in the format string.

voidtest(){mkstemp("XX");// warn}

1.1.7.11.security.insecureAPI.mktemp (C)¶

Warn on uses of themktemp function.

voidtest(){char*x=mktemp("/tmp/zxcv");// warn: insecure, use mkstemp}

1.1.7.12.security.insecureAPI.rand (C)¶

Warn on uses of inferior random number generating functions (only if arc4random function is available):drand48,erand48,jrand48,lcong48,lrand48,mrand48,nrand48,random,rand_r.

voidtest(){random();// warn}

1.1.7.13.security.insecureAPI.strcpy (C)¶

Warn on uses of thestrcpy andstrcat functions.

voidtest(){charx[4];char*y="abcd";strcpy(x,y);// warn}

1.1.7.14.security.insecureAPI.vfork (C)¶

Warn on uses of the ‘vfork’ function.

voidtest(){vfork();// warn}

1.1.7.15.security.insecureAPI.DeprecatedOrUnsafeBufferHandling (C)¶

Warn on occurrences of unsafe or deprecated buffer handling functions, which now have a secure variant:sprintf,fprintf,vsprintf,scanf,wscanf,fscanf,fwscanf,vscanf,vwscanf,vfscanf,vfwscanf,sscanf,swscanf,vsscanf,vswscanf,swprintf,snprintf,vswprintf,vsnprintf,memcpy,memmove,strncpy,strncat,memset

voidtest(){charbuf[5];strncpy(buf,"a",1);// warn}

1.1.7.16.security.MmapWriteExec (C)¶

Warn onmmap() calls with both writable and executable access.

voidtest(intn){void*c=mmap(NULL,32,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE|MAP_ANON,-1,0);// warn: Both PROT_WRITE and PROT_EXEC flags are set. This can lead to//       exploitable memory regions, which could be overwritten with malicious//       code}

1.1.7.17.security.PointerSub (C)¶

Check for pointer subtractions on two pointers pointing to different memorychunks. According to the C standard §6.5.6 only subtraction of pointers thatpoint into (or one past the end) the same array object is valid (for thispurpose non-array variables are like arrays of size 1). This checker onlysearches for different memory objects at subtraction, but does not check if thearray index is correct. Furthermore, only cases are reported wherestack-allocated objects are involved (no warnings on pointers to memoryallocated bymalloc).

voidtest(){inta,b,c[10],d[10];intx=&c[3]-&c[1];x=&d[4]-&c[1];// warn: 'c' and 'd' are different arraysx=(&a+1)-&a;x=&b-&a;// warn: 'a' and 'b' are different variables}structS{intx[10];inty[10];};voidtest1(){structSa[10];structSb;intd=&a[4]-&a[6];d=&a[0].x[3]-&a[0].x[1];d=a[0].y-a[0].x;// warn: 'S.b' and 'S.a' are different objectsd=(char*)&b.y-(char*)&b.x;// warn: different members of the same objectd=(char*)&b.y-(char*)&b;// warn: object of type S is not the same array as a member of it}

There may be existing applications that use code like above for calculatingoffsets of members in a structure, using pointer subtractions. This is stillundefined behavior according to the standard and code like this can be replacedwith theoffsetof macro.

1.1.7.18.security.PutenvStackArray (C)¶

Finds calls to theputenv function which pass a pointer to a stack-allocated(automatic) array as the argument. Functionputenv does not copy the passedstring, only a pointer to the data is stored and this data can be read even byother threads. Content of a stack-allocated array is likely to be overwrittenafter exiting from the function.

The problem can be solved by using a static array variable or dynamicallyallocated memory. Even better is to avoid usingputenv (it has otherproblems related to memory leaks) and usesetenv instead.

The check corresponds to CERT rulePOS34-C. Do not call putenv() with a pointer to an automatic variable as the argument.

intf(){charenv[]="NAME=value";returnputenv(env);// putenv function should not be called with stack-allocated string}

There is one case where the checker can report a false positive. This is whenthe stack-allocated array is used atputenv in a function or code branch thatdoes not return (process is terminated on all execution paths).

Another special case is if theputenv is called from functionmain. Herethe stack is deallocated at the end of the program and it should be no problemto use the stack-allocated string (a multi-threaded program may require moreattention). The checker does not warn for cases when stack space ofmain isused at theputenv call.

1.1.7.19.security.SetgidSetuidOrder (C)¶

When dropping user-level and group-level privileges in a program by usingsetuid andsetgid calls, it is important to reset the group-levelprivileges (withsetgid) first. Functionsetgid will likely fail ifthe superuser privileges are already dropped.

The checker checks for sequences ofsetuid(getuid()) andsetgid(getgid()) calls (in this order). If such a sequence is found andthere is no other privilege-changing function call (seteuid,setreuid,setresuid and the GID versions of these) in between, a warning isgenerated. The checker finds only exactlysetuid(getuid()) calls (and theGID versions), not for example if the result ofgetuid() is stored in avariable.

voidtest1(){// ...// end of section with elevated privileges// reset privileges (user and group) to normal userif(setuid(getuid())!=0){handle_error();return;}if(setgid(getgid())!=0){// warning: A 'setgid(getgid())' call following a 'setuid(getuid())' call is likely to failhandle_error();return;}// user-ID and group-ID are reset to normal user now// ...}

In the code above the problem is thatsetuid(getuid()) removes superuserprivileges beforesetgid(getgid()) is called. To fix the problem thesetgid(getgid()) should be called first. Further attention is needed toavoid code likesetgid(getuid()) (this checker does not detect bugs likethis) and always check the return value of these calls.

This check corresponds to SEI CERT RulePOS36-C.

1.1.7.20.security.VAList (C, C++)¶

Reports use of uninitialized (or already released)va_list objects andsituations where ava_start call is not followed byva_end.

inttest_use_after_release(intx,...){va_listva;va_start(va,x);va_end(va);returnva_arg(va,int);// warn: va is uninitialized}voidtest_leak(intx,...){va_listva;va_start(va,x);}// warn: va is leaked

1.1.8.1.unix.API (C)¶

Check calls to various UNIX/Posix functions:open,pthread_once,calloc,malloc,realloc,alloca.

// Currently the check is performed for apple targets only.voidtest(constchar*path){intfd=open(path,O_CREAT);// warn: call to 'open' requires a third argument when the// 'O_CREAT' flag is set}voidf();voidtest(){pthread_once_tpred={0x30B1BCBA,{0}};pthread_once(&pred,f);// warn: call to 'pthread_once' uses the local variable}voidtest(){void*p=malloc(0);// warn: allocation size of 0 bytes}voidtest(){void*p=calloc(0,42);// warn: allocation size of 0 bytes}voidtest(){void*p=malloc(1);p=realloc(p,0);// warn: allocation size of 0 bytes}voidtest(){void*p=alloca(0);// warn: allocation size of 0 bytes}voidtest(){void*p=valloc(0);// warn: allocation size of 0 bytes}

1.1.8.2.unix.BlockInCriticalSection (C, C++)¶

Check for calls to blocking functions inside a critical section.Blocking functions detected by this checker:sleep,getc,fgets,read,recv.Critical section handling functions modeled by this checker:lock,unlock,pthread_mutex_lock,pthread_mutex_trylock,pthread_mutex_unlock,mtx_lock,mtx_timedlock,mtx_trylock,mtx_unlock,lock_guard,unique_lock.

voidpthread_lock_example(pthread_mutex_t*m){pthread_mutex_lock(m);// note: entering critical section heresleep(10);// warn: Call to blocking function 'sleep' inside of critical sectionpthread_mutex_unlock(m);}

voidoverlapping_critical_sections(mtx_t*m1,std::mutex&m2){std::lock_guardlg{m2};// note: entering critical section heremtx_lock(m1);// note: entering critical section heresleep(10);// warn: Call to blocking function 'sleep' inside of critical sectionmtx_unlock(m1);sleep(10);// warn: Call to blocking function 'sleep' inside of critical section// still inside of the critical section of the std::lock_guard}

Limitations

• Thetrylock andtimedlock versions of acquiring locks are currently assumed to always succeed.This can lead to false positives.

voidtrylock_example(pthread_mutex_t*m){if(pthread_mutex_trylock(m)==0){// assume trylock always succeedssleep(10);// warn: Call to blocking function 'sleep' inside of critical sectionpthread_mutex_unlock(m);}else{sleep(10);// false positive: Incorrect warning about blocking function inside critical section.}}

1.1.8.3.unix.Chroot (C)¶

Check improper use of chroot described by SEI Cert C recommendationPOS05-C.Limit access to files by creating a jail.The checker finds usage patterns wherechdir("/") is not called immediatelyafter a call tochroot(path).

voidf();voidtest_bad(){chroot("/usr/local");f();// warn: no call of chdir("/") immediately after chroot}voidtest_bad_path(){chroot("/usr/local");chdir("/usr");// warn: no call of chdir("/") immediately after chrootf();}voidtest_good(){chroot("/usr/local");chdir("/");// no warningf();}

1.1.8.4.unix.Errno (C)¶

Check for improper use oferrno.This checker implements partially CERT ruleERR30-C. Set errno to zero before calling a library function known to set errno,and check errno only after the function returns a value indicating failure.The checker can find the first read oferrno after successful standardfunction calls.

The C and POSIX standards often do not define if a standard library functionmay change value oferrno if the call does not fail.Therefore,errno should only be used if it is known from the return valueof a function that the call has failed.There are exceptions to this rule (for examplestrtol) but the affectedfunctions are not yet supported by the checker.The return values for the failure cases are documented in the standard Linux manpages of the functions and in thePOSIX standard.

intunsafe_errno_read(intsock,void*data,intdata_size){if(send(sock,data,data_size,0)!=data_size){// 'send' can be successful even if not all data was sentif(errno==1){// An undefined value may be read from 'errno'return0;}}return1;}

The checkerunix.StdCLibraryFunctions (C) must be turned on to get thewarnings from this checker. The supported functions are the same as byunix.StdCLibraryFunctions (C). TheModelPOSIX option of thatchecker affects the set of checked functions.

Parameters

TheAllowErrnoReadOutsideConditionExpressions option allows read of theerrno value if the value is not used in a condition (inif statements,loops, conditional expressions,switch statements). For exampleerrnocan be stored into a variable without getting a warning by the checker.

intunsafe_errno_read(intsock,void*data,intdata_size){if(send(sock,data,data_size,0)!=data_size){interr=errno;// warning if 'AllowErrnoReadOutsideConditionExpressions' is false// no warning if 'AllowErrnoReadOutsideConditionExpressions' is true}return1;}

Default value of this option istrue. This allows save of the errno valuefor possible later error handling.

Limitations

• Only the very first usage oferrno is checked after an affected functioncall. Value oferrno is not followed when it is stored into a variableor returned from a function.

• Documentation of functionlseek is not clear about what happens if thefunction returns different value than the expected file position but not -1.To avoid possible false-positiveserrno is allowed to be used in thiscase.

1.1.8.5.unix.Malloc (C)¶

Check for memory leaks, double free, and use-after-free problems. Traces memory managed by malloc()/free().

Custom allocation/deallocation functions can be defined usingownership attributes.

voidtest(){int*p=malloc(1);free(p);free(p);// warn: attempt to release already released memory}voidtest(){int*p=malloc(sizeof(int));free(p);*p=1;// warn: use after free}voidtest(){int*p=malloc(1);if(p)return;// warn: memory is never released}voidtest(){inta[]={1};free(a);// warn: argument is not allocated by malloc}voidtest(){int*p=malloc(sizeof(char));p=p-1;free(p);// warn: argument to free() is offset by -4 bytes}

1.1.8.6.unix.MallocSizeof (C)¶

Check for dubiousmalloc arguments involvingsizeof.

Custom allocation/deallocation functions can be defined usingownership attributes.

voidtest(){long*p=malloc(sizeof(short));// warn: result is converted to 'long *', which is// incompatible with operand type 'short'free(p);}

1.1.8.7.unix.MismatchedDeallocator (C, C++)¶

Check for mismatched deallocators.

Custom allocation/deallocation functions can be defined usingownership attributes.

// C, C++voidtest(){int*p=(int*)malloc(sizeof(int));deletep;// warn}// C, C++void__attribute((ownership_returns(malloc)))*user_malloc(size_t);void__attribute((ownership_takes(malloc,1)))*user_free(void*);void__attribute((ownership_returns(malloc1)))*user_malloc1(size_t);void__attribute((ownership_takes(malloc1,1)))*user_free1(void*);voidtest(){int*p=(int*)user_malloc(sizeof(int));deletep;// warn}// C, C++voidtest(){int*p=newint;free(p);// warn}// C, C++voidtest(){int*p=newint[1];realloc(p,sizeof(long));// warn}// C, C++voidtest(){int*p=user_malloc(10);user_free1(p);// warn}// C, C++template<typenameT>structSimpleSmartPointer{T*ptr;explicitSimpleSmartPointer(T*p=0):ptr(p){}~SimpleSmartPointer(){deleteptr;// warn}};voidtest(){SimpleSmartPointer<int>a((int*)malloc(4));}// C++voidtest(){int*p=(int*)operatornew(0);delete[]p;// warn}// Objective-C, C++voidtest(NSUIntegerdataLength){int*p=newint;NSData*d=[NSDatadataWithBytesNoCopy:plength:sizeof(int)freeWhenDone:1];// warn +dataWithBytesNoCopy:length:freeWhenDone: cannot take// ownership of memory allocated by 'new'}