=?utf-8?q?Donát?= Nagy <donat.n...@ericsson.com>
Message-ID:
In-Reply-To: <llvm.org/llvm/llvm-project/pull/83...@github.com>
================
@@ -27,20 +27,48 @@ class IdentifierInfo;
namespace clang {
namespace ento {
-
-enum CallDescriptionFlags : unsigned {
- CDF_None = 0,
-
- /// Describes a C standard function that is sometimes implemented as a macro
- /// that expands to a compiler builtin with some __builtin prefix.
- /// The builtin may as well have a few extra arguments on top of the
requested
- /// number of arguments.
- CDF_MaybeBuiltin = 1 << 0,
-};
-
-/// This class represents a description of a function call using the number of
-/// arguments and the name of the function.
+/// A `CallDescription` is a pattern that can be used to _match_ calls
+/// based on the qualified name and the argument/parameter counts.
class CallDescription {
+public:
+ enum class Mode {
+ /// Match calls to functions from the C standard library. On some platforms
+ /// some functions may be implemented as macros that expand to calls to
+ /// built-in variants of the given functions, so in this mode we use some
+ /// heuristics to recognize these implementation-defined variants:
+ /// - We also accept calls where the name is derived from the specified
+ /// name by adding "__builtin" or similar prefixes/suffixes.
+ /// - We also accept calls where the number of arguments or parameters is
+ /// greater than the specified value.
+ /// For the exact heuristics, see CheckerContext::isCLibraryFunction().
+ /// Note that functions whose declaration context is not a TU (e.g.
+ /// methods, functions in namespaces) are not accepted as C library
+ /// functions.
+ /// FIXME: If I understand it correctly, this discards calls where C++ code
+ /// refers a C library function through the namespace `std::` via headers
+ /// like <cstdlib>.
+ CLibrary,
----------------
NagyDonat wrote:
> many functions that are "C library" calls are not matched with this mode
I'm planning to ensure that:
- this mode works "out of the box" for matching the C standard library
functions and
- the checkers that are looking for a C standard library function do use it.
This is an NFC commit so I didn't change the behavior of this mode yet, but I'm
planning to do so in a followup commit. I picked the name `CLibrary` because it
reflects the name of the method `isCLibraryFunction()` which is used to
implement this mode. I'd say that if `isCLibraryFunction()` returns false for a
C library function, then it's buggy and I'll fix its behavior.
Do you see any difficulties that would hinder or block this path?
By the way I dislike the name `MaybeBuiltin` because at first I thought that
that it clearly meant "this _may be_ a builtin function (with a modified name),
but it _may be_ anything else as well", while in fact it always calls
`isCLibraryFunction` (and doesn't accept anything that isn't a C library
function).
https://github.com/llvm/llvm-project/pull/83432
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
