This check implements the typebased semantic of `gsl::owner`.
Meaning, that
- only `gsl::owner` is allowed to get `delete`d
- `new` expression must be assigned to `gsl::owner`
- function calls that expect `gsl::owner` as argument, must get either an owner
or a newly created and recognized resource (in the moment only `new`ed memory)
- assignment to `gsl::owner` must be either a resource or another owner
- functions returning an `gsl::owner` are considered as factories, and their result
must be assigned to an `gsl::owner`
- classes that have an `gsl::owner`-member must declare a non-default destructor
There are some problems that occur when typededuction is in place.
For example `auto Var = function_that_returns_owner();` the type of `Var` will not be
an `gsl::owner`. This case is catched, and explicitly noted.
But cases like fully templated functions
```
template <typename T>
void f(T t) { delete t; }
// ...
f(gsl::owner<int*>(new int(42)));
```
Will created false positive (the deletion is problematic), since the type deduction
removes the wrapping `typeAlias`.
Codereview in D36354
llvm-svn: 313067
This check implements the typebased semantic of `gsl::owner`.
Meaning, that
- only `gsl::owner` is allowed to get `delete`d
- `new` expression must be assigned to `gsl::owner`
- function calls that expect `gsl::owner` as argument, must get either an owner
or a newly created and recognized resource (in the moment only `new`ed memory)
- assignment to `gsl::owner` must be either a resource or another owner
- functions returning an `gsl::owner` are considered as factories, and their result
must be assigned to an `gsl::owner`
- classes that have an `gsl::owner`-member must declare a non-default destructor
There are some problems that occur when typededuction is in place.
For example `auto Var = function_that_returns_owner();` the type of `Var` will not be
an `gsl::owner`. This case is catched, and explicitly noted.
But cases like fully templated functions
```
template <typename T>
void f(T t) { delete t; }
// ...
f(gsl::owner<int*>(new int(42)));
```
Will created false positive (the deletion is problematic), since the type deduction
removes the wrapping `typeAlias`.
Please give your comments :)
llvm-svn: 313043
This patch will introduce even more aliases for the hicpp-module to already existing
checks and is a follow up for D30383 finishing the other sections.
It fixes a forgotten highlight in hicpp-braces-around-statements.rst, too.
llvm-svn: 312901
Summary:
epoll_create() is better to be replaced by epoll_create1() with EPOLL_CLOEXEC
flag to avoid file descriptor leakage.
Differential Revision: https://reviews.llvm.org/D35367
llvm-svn: 311029
Summary:
epoll_create1() is better to set EPOLL_CLOEXEC flag to avoid file descriptor leakage.
Differential Revision: https://reviews.llvm.org/D35365
llvm-svn: 311028
Summary:
accept4() is better to set SOCK_CLOEXEC flag to avoid file descriptor leakage.
Differential Revision: https://reviews.llvm.org/D35363
llvm-svn: 311027
Summary:
accept() is better to be replaced by accept4() with SOCK_CLOEXEC
flag to avoid file descriptor leakage.
Differential Revision: https://reviews.llvm.org/D35362
llvm-svn: 311024
Summary:
inotify_init1() is better to set IN_CLOEXEC flag to avoid file descriptor leakage.
Differential Revision: https://reviews.llvm.org/D35368
llvm-svn: 310863
Summary:
inotify_init() is better to be replaced by inotify_init1() with IN_CLOEXEC flag to avoid file descriptor leakage.
Differential Revision: https://reviews.llvm.org/D35370
llvm-svn: 310861
Summary:
dup() is better to be replaced by fcntl() to avoid file descriptor leakage.
Differential Revision: https://reviews.llvm.org/D35364
llvm-svn: 310858
This reverts commit r310630.
The new code broke on Windows and was untested. On Linux, it was
selecting the "int" overload of operator<<, which definitely does not
print the right thing when fed a "Mode" char.
llvm-svn: 310661
Summary:
1. Refactor the structure of the code by adding a base class for all close-on-exec checks, which implements most of the needed functions.
2. memfd_create() is better to set MFD_CLOEXEC flag to avoid file descriptor leakage.
Reviewers: alexfh, aaron.ballman, hokein
Reviewed By: alexfh, hokein
Subscribers: Eugene.Zelenko, chh, cfe-commits, srhines, mgorny, JDevlieghere, xazax.hun
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D35372
llvm-svn: 310630
Summary: Adds redirections notes and the actual redirections in the documentation for hicpp
Patch by: Jonas Toth
Reviewers: aaron.ballman, hokein, alexfh
Reviewed By: aaron.ballman, hokein
Subscribers: JDevlieghere, xazax.hun
Differential Revision: https://reviews.llvm.org/D36355
llvm-svn: 310577
Summary:
This patch renames checks, check options and changes messages to use correct
term "implicit conversion" instead of "implicit cast" (which has been in use in
Clang AST since ~10 years, but it's still technically incorrect w.r.t. C++
standard).
* performance-implicit-cast-in-loop -> performance-implicit-conversion-in-loop
* readability-implicit-bool-cast -> readability-implicit-bool-conversion
- readability-implicit-bool-cast.AllowConditionalIntegerCasts ->
readability-implicit-bool-conversion.AllowIntegerConditions
- readability-implicit-bool-cast.AllowConditionalPointerCasts ->
readability-implicit-bool-conversion.AllowPointerConditions
Reviewers: hokein, jdennett
Reviewed By: hokein
Subscribers: mgorny, JDevlieghere, xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D36456
llvm-svn: 310366
Summary:
The check doesn't fully support smart-ptr usages inside macros, which
may cause incorrect fixes, or even crashes, ignore them for now.
Reviewers: alexfh
Reviewed By: alexfh
Subscribers: JDevlieghere, xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D36264
llvm-svn: 310050
Created new module bugprone and placed the check in that.
Finds memset() calls with potential mistakes in their arguments.
Replaces and extends the existing google-runtime-memset-zero-length check.
Cases covered:
* Fill value is a character '0'. Integer 0 might have been intended.
* Fill value is out of char range and gets truncated.
* Byte count is zero. Potentially swapped with the fill value argument.
Patch by: Reka Nikolett Kovacs
Differential Revision: https://reviews.llvm.org/D32700
llvm-svn: 308020
Summary: socket() is better to include SOCK_CLOEXEC in its type argument to avoid the file descriptor leakage.
Reviewers: chh, Eugene.Zelenko, alexfh, hokein, aaron.ballman
Reviewed By: chh, alexfh
Subscribers: srhines, mgorny, JDevlieghere, xazax.hun, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D34913
llvm-svn: 307818
Summary:
1. Rename android-file-open-flag to android-cloexec-open.
2. Handle a case when the function is passed as an argument of a function-like macro.
Reviewers: chh
Reviewed By: chh
Subscribers: srhines, mgorny, JDevlieghere, xazax.hun, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D34633
llvm-svn: 306728
Summary:
A follow-up on D34449:
* add `-std=c++11` to `.hpp` file by default.
* add constexpr function to test and doc.
Reviewers: alexfh
Reviewed By: alexfh
Subscribers: JDevlieghere, xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D34771
llvm-svn: 306650
* Enforce 80 characters limit where appropriate
* Use slightly more descriptive names for searched locations
* Update docs to reflect D34269, which adds "Go To Declaration" functionality
llvm-svn: 306598
Summary:
A common source of security bugs is code that opens a file descriptors without using the O_CLOEXEC flag. (Without that flag, an opened sensitive file would remain open across a fork+exec to a lower-privileged SELinux domain, leaking that sensitive data.).
Add a new Android module and one checks in clang-tidy.
-- open(), openat(), and open64() should include O_CLOEXEC in their flags argument. [android-file-open-flag]
Links to part2 and part3:
https://reviews.llvm.org/D33745https://reviews.llvm.org/D33747
Reviewers: chh, alexfh, aaron.ballman, hokein
Reviewed By: alexfh, hokein
Subscribers: jbcoe, joerg, malcolm.parsons, Eugene.Zelenko, srhines, mgorny, xazax.hun, cfe-commits, krytarowski
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D33304
llvm-svn: 306165