According to
https://wiki.sei.cmu.edu/confluence/display/c/CON37-C.+Do+not+call+signal%28%29+in+a+multithreaded+program
bugprone-signal-in-multithreaded-program check is created.
The check finds signal function call when the program is
multithreaded.
Details
- Reviewers
aaron.ballman alexfh hokein jfb
Diff Detail
- Repository
- rCTE Clang Tools Extra
Event Timeline
Will be good idea to make callers function list configurable through option. See other checks as example.
clang-tools-extra/clang-tidy/bugprone/SignalInMultithreadedProgramCheck.cpp | ||
---|---|---|
21 | Unnecessary empty line. | |
clang-tools-extra/docs/ReleaseNotes.rst | ||
135 | Please add empty line above. | |
clang-tools-extra/docs/clang-tidy/checks/bugprone-signal-in-multithreaded-program.rst | ||
13 | Should be double colon. | |
19 | Please enclose signal() in double back-ticks. |
clang-tools-extra/clang-tidy/bugprone/SignalInMultithreadedProgramCheck.cpp | ||
---|---|---|
34–51 | I apologize for interrupting the review. Wouldn't it be more performant to collect all the signal calls in a set and set a bool variable if a ThreadList function seen? Treat this comment rather a question since I'm not really familiar with clang-tidy. |
clang-tools-extra/clang-tidy/bugprone/SignalInMultithreadedProgramCheck.cpp | ||
---|---|---|
34–51 | I updated the checker not exactly in that way you mentioned, but I think you are right that we should not match for all translationUnitDecl. |
clang-tools-extra/clang-tidy/bugprone/SignalInMultithreadedProgramCheck.cpp | ||
---|---|---|
34–51 | Every single check runs on the whole TranslationUnitDecl, and the matcher will try to match on every of the TU's descendant, that is why it emit multiple reports in the same single run. There is no need to use translationUnitDecl() and nor to use forEachDescendant(). | |
39 | You can emit the binding of thread. | |
57 | singal -> signal |
Minor nits inline. Good job, I am not entitled to accept it, but LGTM!
clang-tools-extra/clang-tidy/bugprone/SignalInMultithreadedProgramCheck.h | ||
---|---|---|
24 | Or better: |
clang-tools-extra/clang-tidy/bugprone/SignalInMultithreadedProgramCheck.h | ||
---|---|---|
24 | Clang-tidy uses check. |
clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp | ||
---|---|---|
89 | Please use check here. |
clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp | ||
---|---|---|
89 | Should I replace the // C++ checkers comment too? I mean to // C++ checks instead of // C++ checkers? |
clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp | ||
---|---|---|
89 | Sure. It's good idea to keep user and developer terminology consistent. |
In general, the test files should be cleaned up.
clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-in-multithreaded-program-config-std::thread.cpp | ||
---|---|---|
1 ↗ | (On Diff #271789) | Please rename this file to something that doesn't conatain : in the name. Windows peoples' computers will explode if it's merged like this... |
5–6 ↗ | (On Diff #271789) | Are these definitions needed for C++ test? |
32 ↗ | (On Diff #271789) | As far as I know, int main(void) is not valid C++ code. Only int main() and int main(int, char**) are valid, see [basic.start.main]/2. If we are writing C++ test code, let's make it appear as if it was C++ code. |
clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-in-multithreaded-program-noconfig-std::thread.cpp | ||
1 ↗ | (On Diff #271789) | Same rename here. |
clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-in-multithreaded-program-noconfig-thrd_create.cpp | ||
1 ↗ | (On Diff #271789) | thrd_create is a C standard function, and this file looks like a C file to me, so why is the extension .cpp? |
It seems like you don't want this check to trigger on POSIX platforms, given:
Exceptions CON37-C-EX1: Implementations such as POSIX that provide defined behavior when multithreaded programs use custom signal handlers are exempt from this rule [IEEE Std 1003.1-2013].
I have managed to improve the checker, but could not set up the test files to work only in POSIX platforms. Could you help me or show me an example?
It's more so that, if I understand correctly, you don't want the diagnostics to be emitted when dealing with POSIX multithreading.
Also, have you checked in the test if __unix__ is defined? I'm not seeing any indication of targets in the test configuration, nor checking for this macro. Maybe a Windows-specific test file should be added? clang/test/Preprocessor/init.c lists a bunch of macros that are supposedly pre-defined based on the target.
Or maybe the OSType in the triple would be more useful than the vendor?
clang-tools-extra/clang-tidy/bugprone/SignalInMultithreadedProgramCheck.cpp | ||
---|---|---|
69 | Global state is always a potential problem. Are you sure this is the right way to do things? Most other tidy checks that actively use this function define their own PPCallback subclass and use the existing preprocessor here to ensure the preprocessor executes the callback. | |
clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp | ||
50–85 | Please upload the diff with full context. | |
clang-tools-extra/docs/clang-tidy/checks/list.rst | ||
102 | There is a table in this file towards the end where alias checks are explicitly listed in a "which check is alias of which other check" format. |
clang-tools-extra/clang-tidy/bugprone/SignalInMultithreadedProgramCheck.cpp | ||
---|---|---|
42 | ::std::thread | |
48 | ::signal | |
57 | This does not seem like the right way to check for POSIX -- isn't that _POSIX_C_SOURCE? | |
clang-tools-extra/clang-tidy/bugprone/SignalInMultithreadedProgramCheck.h | ||
25 | The comment is a bit stale as it also accepts user-defined functions. Note, I think CreateThread, CreateRemoteThread, _beginthread, and _beginthreadex should be added to the list as those are the common Win32 APIs for creating threads (where pthreads aren't available). | |
35 | I think that should be ::std::thread and ::boost::thread to avoid pathological naming issues. |
clang-tools-extra/clang-tidy/bugprone/SignalInMultithreadedProgramCheck.cpp | ||
---|---|---|
69 | I've used the same way in another check (https://reviews.llvm.org/D69181). I'm not entirely sure which is the better way to do. |
clang-tools-extra/clang-tidy/bugprone/SignalInMultithreadedProgramCheck.cpp | ||
---|---|---|
58 | Nothing for you to change here, but this demonstrates that isLanguageVersionSupported() isn't sufficient. We don't want to register the check at all for POSIX platforms in the same way we don't want to register checks at all based on the language standard being enforced, but we can't because we can't get to the Preprocessor or target information from there. | |
69 | Defining the PPCallback subclass is a better approach (https://github.com/llvm/llvm-project/blob/e40a742a5008c5a4cf647c0ea805486498786393/clang-tools-extra/clang-tidy/cert/SetLongJmpCheck.cpp#L49 shows a reasonable demonstration). At the very least, this doesn't have to set a global variable, it could set a member variable on SignalInMultithreadedProgramCheck. I hadn't caught that in D69181, sorry about that! | |
clang-tools-extra/clang-tidy/bugprone/SignalInMultithreadedProgramCheck.h | ||
25 | The comment has gone stale again. Rather than listing the functions in the comment, I think it's fine to change it to: ... if it finds at least one threading-related function. | |
clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp | ||
91 | We try to keep these in order, so this should move down below con36-c. |
Most of the tests as written should be failing right now, at least on macOS and Linux, because they likely should be identified as POSIX, right?
Fix, MacroName == "__unix__" seems really necessary. Without that, it throws a warning for me on Linux.
founds -> finds, but I would rather reword it like this:
The checker considers the analyzed program multithreaded if it finds ....