[PATCH] D118996: [clang-tidy] Support C++14 in bugprone-signal-handler.

Tue Mar 29 02:24:36 PDT 2022

whisperity added inline comments.

================
Comment at: clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp:153
+    diag(HandlerLambda->getBeginLoc(),
+         "lambda function is not allowed as signal handler (until C++17)")
+        << HandlerLambda->getSourceRange();
----------------
balazske wrote:
> whisperity wrote:
> > I am trying to find some source for this claim but so far hit a blank. 😦 Could you please elaborate where this information comes from? Most notably, [[ https://en.cppreference.com/w/cpp/utility/program/signal | std::signal on CppReference ]] makes no mention of this, which would be the first place I would expect most people to look at.
> > 
> > Maybe this claim is derived from the rule that signal handlers **MUST** have C linkage? (If so, is there a warning against people setting C++-linkage functions as signal handlers in this check in general?)
> This check is made to comply with a CERT rule [[ https://wiki.sei.cmu.edu/confluence/display/cplusplus/MSC54-CPP.+A+signal+handler+must+be+a+plain+old+function | MSC54-CPP ]]. According to this only the subset of C and C++ should be used in a signal handler, and it should have extern "C" linkage. This does not allow lambda functions because the linkage restriction (if not others). (From C++17 on other rules apply, this check is not applicable for such code.)
Ah, right, I found it a bit further down the page:

> //Signal handlers are expected to have C linkage// and, in general, only use the features from the common subset of C and C++. It is implementation-defined if a function with C++ linkage can be used as a signal handler. (until C++17)

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D118996/new/

https://reviews.llvm.org/D118996