[analyzer] Add path note tags to standard library function summaries.

The patch is straightforward except the tiny fix in BugReporterVisitors.cpp
that suppresses a default note for "Assuming pointer

[analyzer] Add path note tags to standard library function summaries.

The patch is straightforward except the tiny fix in BugReporterVisitors.cpp
that suppresses a default note for "Assuming pointer value is null" when
a note tag from the checker is present. This is probably the right thing to do
but also definitely not a complete solution to the problem of different sources
of path notes being unaware of each other, which is a large and annoying issue
that we have to deal with. Note tags really help there because they're nicely
introspectable. The problem is demonstrated by the newly added getenv() test.

Differential Revision: https://reviews.llvm.org/D122285

show more ...

[analyzer] Clean checker options from bool to DefaultBool (NFC)

A recent review emphasized the preference to use DefaultBool instead of
bool for checker options. This change is a NFC and cleans up s

[analyzer] Clean checker options from bool to DefaultBool (NFC)

A recent review emphasized the preference to use DefaultBool instead of
bool for checker options. This change is a NFC and cleans up some of the
instances where bool was used, and could be changed to DefaultBool.

Reviewed By: steakhal

Differential Revision: https://reviews.llvm.org/D123464

show more ...

[clang][NFC] Inclusive terms: replace some uses of sanity in clang

Rewording of comments to avoid using `sanity test, sanity check`.

Reviewed By: aaron.ballman, Quuxplusone

Differential Revision:

[clang][NFC] Inclusive terms: replace some uses of sanity in clang

Rewording of comments to avoid using `sanity test, sanity check`.

Reviewed By: aaron.ballman, Quuxplusone

Differential Revision: https://reviews.llvm.org/D114025

show more ...

[analyzer] Introduce the assume-controlled-environment config option

If the `assume-controlled-environment` is `true`, we should expect `getenv()`
to succeed, and the result should not be considered

[analyzer] Introduce the assume-controlled-environment config option

If the `assume-controlled-environment` is `true`, we should expect `getenv()`
to succeed, and the result should not be considered tainted.
By default, the option will be `false`.

Reviewed By: NoQ, martong

Differential Revision: https://reviews.llvm.org/D111296

show more ...

[analyzer] Bifurcate on getenv() calls

The `getenv()` function might return `NULL` just like any other function.
However, in case of `getenv()` a state-split seems justified since the
programmer sho

[analyzer] Bifurcate on getenv() calls

The `getenv()` function might return `NULL` just like any other function.
However, in case of `getenv()` a state-split seems justified since the
programmer should expect the failure of this function.

`secure_getenv(const char *name)` behaves the same way but is not handled
right now.
Note that `std::getenv()` is also not handled.

Reviewed By: martong

Differential Revision: https://reviews.llvm.org/D111245

show more ...

[analyzer][StdLibraryFunctionsChecker] Track dependent arguments

When we report an argument constraint violation, we should track those
other arguments that participate in the evaluation of the viol

[analyzer][StdLibraryFunctionsChecker] Track dependent arguments

When we report an argument constraint violation, we should track those
other arguments that participate in the evaluation of the violation. By
default, we depend only on the argument that is constrained, however,
there are some special cases like the buffer size constraint that might
be encoded in another argument(s).

Differential Revision: https://reviews.llvm.org/D101358

show more ...

[Analyzer][StdLibraryFunctionsChecker] Describe arg constraints

In this patch, I provide a detailed explanation for each argument
constraint. This explanation is added in an extra 'note' tag, which

[Analyzer][StdLibraryFunctionsChecker] Describe arg constraints

In this patch, I provide a detailed explanation for each argument
constraint. This explanation is added in an extra 'note' tag, which is
displayed alongside the warning.
Since these new notes describe clearly the constraint, there is no need
to provide the number of the argument (e.g. 'Arg3') within the warning.
However, I decided to keep the name of the constraint in the warning (but
this could be a subject of discussion) in order to be able to identify
the different kind of constraint violations easily in a bug database
(e.g. CodeChecker).

Differential Revision: https://reviews.llvm.org/D101060

show more ...

[analyzer] DynamicSize: Rename 'size' to 'extent'

Make iteration over the DeclContext::lookup_result safe.

The idiom:
```
DeclContext::lookup_result R = DeclContext::lookup(Name);
for (auto *D : R) {...}
```

is not safe when in the loop body we tr

Make iteration over the DeclContext::lookup_result safe.

The idiom:
```
DeclContext::lookup_result R = DeclContext::lookup(Name);
for (auto *D : R) {...}
```

is not safe when in the loop body we trigger deserialization from an AST file.
The deserialization can insert new declarations in the StoredDeclsList whose
underlying type is a vector. When the vector decides to reallocate its storage
the pointer we hold becomes invalid.

This patch replaces a SmallVector with an singly-linked list. The current
approach stores a SmallVector<NamedDecl*, 4> which is around 8 pointers.
The linked list is 3, 5, or 7. We do better in terms of memory usage for small
cases (and worse in terms of locality -- the linked list entries won't be near
each other, but will be near their corresponding declarations, and we were going
to fetch those memory pages anyway). For larger cases: the vector uses a
doubling strategy for reallocation, so will generally be between half-full and
full. Let's say it's 75% full on average, so there's N * 4/3 + 4 pointers' worth
of space allocated currently and will be 2N pointers with the linked list. So we
break even when there are N=6 entries and slightly lose in terms of memory usage
after that. We suspect that's still a win on average.

Thanks to @rsmith!

Differential revision: https://reviews.llvm.org/D91524

show more ...

[analyzer] Fix StdLibraryFunctionsChecker performance issue

`initFunctionSummaries` lazily initializes a data structure with
function summaries for standard library functions. It is called for
ever

[analyzer] Fix StdLibraryFunctionsChecker performance issue

`initFunctionSummaries` lazily initializes a data structure with
function summaries for standard library functions. It is called for
every pre-, post-, and eval-call events, i.e. 3 times for each call on
the path. If the initialization doesn't find any standard library
functions in the translation unit, it will get re-tried (with the same
effect) many times even for small translation units.

For projects not using standard libraries, the speed-up can reach 50%
after this patch.

Differential Revision: https://reviews.llvm.org/D98244

show more ...

Fix null dereference static analysis warning. NFCI.

Replace cast_or_null<> with cast<> as we immediately dereference the pointer afterward so we're not expecting a null pointer.

[analyzer][StdLibraryFunctionsChecker] Add more return value contraints

This time, we add contraints to functions that either return with [0, -1] or
with a file descriptor.

Differential Revision: h

[analyzer][StdLibraryFunctionsChecker] Add more return value contraints

This time, we add contraints to functions that either return with [0, -1] or
with a file descriptor.

Differential Revision: https://reviews.llvm.org/D92771

show more ...

[analyzer][StdLibraryFunctionsChecker] Make close and mmap to accept -1 as fd

close:
It is quite often that users chose to call close even if the fd is
negative. Theoretically, it would be nicer to

[analyzer][StdLibraryFunctionsChecker] Make close and mmap to accept -1 as fd

close:
It is quite often that users chose to call close even if the fd is
negative. Theoretically, it would be nicer to close only valid fds, but
in practice the implementations of close just returns with EBADF in case
of a non-valid fd param. So, we can eliminate many false positives if we
let close to take -1 as an fd. Other negative values are very unlikely,
because open and other fd factories return with -1 in case of failure.

mmap:
In the case of MAP_ANONYMOUS flag (which is supported e.g. in Linux) the
mapping is not backed by any file; its contents are initialized to zero.
The fd argument is ignored; however, some implementations require fd to
be -1 if MAP_ANONYMOUS (or MAP_ANON) is specified, and portable
applications should ensure this.
Consequently, we must allow -1 as the 4th arg.

Differential Revision: https://reviews.llvm.org/D92764

show more ...

[analyzer][StdLibraryFunctionsChecker] Add return value constraint to functions with BufferSize

Differential Revision: https://reviews.llvm.org/D92474

[analyzer][StdLibraryFunctionsChecker] Fix typos in summaries of mmap and mmap64

The fd parameter of
```
void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset)
```
should b

[analyzer][StdLibraryFunctionsChecker] Fix typos in summaries of mmap and mmap64

The fd parameter of
```
void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset)
```
should be constrained to the range [0, IntMax] as that is of type int.
Constraining to the range [0, Off_tMax] would result in a crash as that is
of a signed type with the value of 0xff..f (-1).

The crash would happen when we try to apply the arg constraints.
At line 583: assert(Min <= Max), as 0 <= -1 is not satisfied

The mmap64 is fixed for the same reason.

Reviewed By: martong, vsavchenko

Differential Revision: https://reviews.llvm.org/D92307

show more ...

[analyzer][StdLibraryFunctionsChecker] Separate the signature from the summaries

The signature should not be part of the summaries as many FIXME comments
suggests. By separating the signature, we op

[analyzer][StdLibraryFunctionsChecker] Separate the signature from the summaries

The signature should not be part of the summaries as many FIXME comments
suggests. By separating the signature, we open up the way to a generic
matching implementation which could be used later under the hoods of
CallDescriptionMap.

Differential Revision: https://reviews.llvm.org/D88100

show more ...

[analyzer][StdLibraryFunctionsChecker] Fix getline/getdelim signatures

It is no longer needed to add summaries of 'getline' for different
possible underlying types of ssize_t. We can just simply loo

[analyzer][StdLibraryFunctionsChecker] Fix getline/getdelim signatures

It is no longer needed to add summaries of 'getline' for different
possible underlying types of ssize_t. We can just simply lookup the
type.

Differential Revision: https://reviews.llvm.org/D88092

show more ...

[analyzer][StdLibraryFunctionsChecker] Elaborate the summary of fread and fwrite

Add the BufferSize argument constraint to fread and fwrite. This change
itself makes it possible to discover a securi

[analyzer][StdLibraryFunctionsChecker] Elaborate the summary of fread and fwrite

Add the BufferSize argument constraint to fread and fwrite. This change
itself makes it possible to discover a security critical case, described
in SEI-CERT ARR38-C.

We also add the not-null constraint on the 3rd arguments.

In this patch, I also remove those lambdas that don't take any
parameters (Fwrite, Fread, Getc), thus making the code better
structured.

Differential Revision: https://reviews.llvm.org/D87081

show more ...

[analyzer][StdLibraryFunctionsChecker] Add better diagnostics

Differential Revision: https://reviews.llvm.org/D79431

[analyzer][StdLibraryFunctionsChecker] Remove strcasecmp

There are 2 reasons to remove strcasecmp and strncasecmp.
1) They are also modeled in CStringChecker and the related argumentum
contraints

[analyzer][StdLibraryFunctionsChecker] Remove strcasecmp

There are 2 reasons to remove strcasecmp and strncasecmp.
1) They are also modeled in CStringChecker and the related argumentum
contraints are checked there.
2) The argument constraints are checked in CStringChecker::evalCall.
This is fundamentally flawed, they should be checked in checkPreCall.
Even if we set up CStringChecker as a weak dependency for
StdLibraryFunctionsChecker then the latter reports the warning always.
Besides, CStringChecker fails to discover the constraint violation
before the call, so, its evalCall returns with `true` and then
StdCLibraryFunctions also tries to evaluate, this causes an assertion
in CheckerManager.

Either we fix CStringChecker to handle the call prerequisites in
checkPreCall, or we must not evaluate any pure functions in
StdCLibraryFunctions that are also handled in CStringChecker.
We do the latter in this patch.

Differential Revision: https://reviews.llvm.org/D87239

show more ...

[analyzer][StdLibraryFunctionsChecker] Add POSIX pthread handling functions

Differential Revision: https://reviews.llvm.org/D84415

[analyzer][StdLibraryFunctionsChecker] Add POSIX time handling functions

Differential Revision: https://reviews.llvm.org/D84248

[analyzer][StdLibraryFunctionsChecker] Do not match based on the restrict qualifier in C++

The "restrict" keyword is illegal in C++, however, many libc
implementations use the "__restrict" compiler

[analyzer][StdLibraryFunctionsChecker] Do not match based on the restrict qualifier in C++

The "restrict" keyword is illegal in C++, however, many libc
implementations use the "__restrict" compiler intrinsic in functions
prototypes. The "__restrict" keyword qualifies a type as a restricted type
even in C++.
In case of any non-C99 languages, we don't want to match based on the
restrict qualifier because we cannot know if the given libc implementation
qualifies the paramter type or not.

Differential Revision: https://reviews.llvm.org/D87097

show more ...

[analyzer][StdLibraryFunctionsChecker] Use Optionals throughout the summary API

By using optionals, we no longer have to check the validity of types that we
get from a lookup. This way, the definiti

[analyzer][StdLibraryFunctionsChecker] Use Optionals throughout the summary API

By using optionals, we no longer have to check the validity of types that we
get from a lookup. This way, the definition of the summaries have a declarative
form, there are no superflous conditions in the source code.

Differential Revision: https://reviews.llvm.org/D86531

show more ...

[analyzer] StdLibraryFunctionsChecker: Add support for new functions

`toupper`, `tolower`, `toascii` functions were added to
StdLibraryFunctionsChecker to fully cover CERT STR37-C rule:
https://wiki

[analyzer] StdLibraryFunctionsChecker: Add support for new functions

`toupper`, `tolower`, `toascii` functions were added to
StdLibraryFunctionsChecker to fully cover CERT STR37-C rule:
https://wiki.sei.cmu.edu/confluence/x/BNcxBQ

Differential Revision: https://reviews.llvm.org/D85093

show more ...