[PATCH] D79423: [analyzer][NFC] StdLibraryFunctionsChecker: Add empty Signatures

Wed May 6 08:35:42 PDT 2020

martong added a comment.

In D79423#2022251 <https://reviews.llvm.org/D79423#2022251>, @xazax.hun wrote:

> I am a bit unsure about this change. C libraries might be consumed in C++ projects and C++ projects might be free to overload those functions.

I don't think that could be a concern.
Actually, redefinition of a reserved name either in the C or in the C++ standard library is undefined behavior:

C++11:
[reserved.names]

1. The C ++ standard library reserves the following kinds of names:

— macros
— global names
— names with external linkage
...
Each name from the Standard C library declared with external linkage is reserved to the implementation
for use as a name with extern "C" linkage, both in namespace std and in the global namespace.

2. If a program declares or defines a name in a context where it is reserved, other than as explicitly allowed by this Clause, its behavior is undefined.

C99 (7.1) has something similar. And from glibc manual <https://www.gnu.org/software/libc/manual/html_node/Reserved-Names.html>:
The names of all library types, macros, variables and functions that come from the ISO C standard are reserved unconditionally; your program may not redefine these names. All other library names are reserved if your program explicitly includes the header file that defines or declares them.

On the other hand, we may be able to discover the mentioned UB, and it may be worth to emit a bug-report in such cases.

> Does the effort needed to specify the signatures justify not supporting that (probably unintentional) name collisions in C++?

No, we still support adding summaries to overloaded C++ functions. But then the user must specify the signature (possibly with `Irrelevant` types) that matches only one FunctionDecl. Hope this answers your question.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79423