clang-tidy misc-include-cleaner should not mark standard headers

[H-Wadman]

Note: I am currently on using clang-tidy provided with the llvm 20.1.2 package from homebrew.

I am currently using clang-tidy with the misc-include-cleaner to, well, keep my includes clean. However I keep getting warnings on standard headers, that in my opinion should not be marked. See for example this case:

This file is including string.h, which is standardised to have NULL defined (see cppreference), but on my current platform (MacOS Sonoma 14.0), the standard library headers define NULL via transitive includes. In fact when I checked the cstring header provided via my llvm 20.1.2 libc++ it also does not define NULL directly. It would be nice (if considered feasible) to take C/C++ standards into account when considering missing includes in order to minimise changes with the sole purpose of satisfying the linter, without improvement to code quality.

[llvmbot]

@llvm/issue-subscribers-clang-tidy

Author: None (H-Wadman)

Note: I am currently on using clang-tidy provided with the llvm 20.1.2 package from homebrew.

I am currently using clang-tidy with the misc-include-cleaner to, well, keep my includes clean. However I keep getting warnings on standard headers, that in my opinion should not be marked. See for example this case:

<img width="1058" alt="Image" src="https://github.com/user-attachments/assets/0887b7f0-eec7-4a6a-9d8e-60d226092f39" />

This file is including string.h, which is standardised to have NULL defined (see cppreference), but on my current platform (MacOS Sonoma 14.0), the standard library headers define NULL via transitive includes. In fact when I checked the cstring header provided via my llvm 20.1.2 libc++ it also does not define NULL directly. It would be nice (if considered feasible) to take C/C++ standards into account when considering missing includes in order to minimise changes with the sole purpose of satisfying the linter, without improvement to code quality.

[llvmbot]

@llvm/issue-subscribers-clang-include-cleaner

Author: None (H-Wadman)

Note: I am currently on using clang-tidy provided with the llvm 20.1.2 package from homebrew.

I am currently using clang-tidy with the misc-include-cleaner to, well, keep my includes clean. However I keep getting warnings on standard headers, that in my opinion should not be marked. See for example this case:

<img width="1058" alt="Image" src="https://github.com/user-attachments/assets/0887b7f0-eec7-4a6a-9d8e-60d226092f39" />

This file is including string.h, which is standardised to have NULL defined (see cppreference), but on my current platform (MacOS Sonoma 14.0), the standard library headers define NULL via transitive includes. In fact when I checked the cstring header provided via my llvm 20.1.2 libc++ it also does not define NULL directly. It would be nice (if considered feasible) to take C/C++ standards into account when considering missing includes in order to minimise changes with the sole purpose of satisfying the linter, without improvement to code quality.

[firewave]

This file is including string.h, which is standardised to have NULL defined (see cppreference)

Actually that documentation is not the standard. It specifies some headers as providing symbols which commonly provide those but are not actually the canonical source (there were some edits without much context a few years ago which introduced those in several pages).

These common assumption are also fueled by the general reliance on transitive headers. To resolving those in one of the reason why you should run something like include-what-you-use and clang-includer-cleaner. They are not just about getting rid of unused stuff but making sure your files are fully-contained (headers) or explicitly specify all dependencies. That is also something libc++ actively working towards with -D_LIBCPP_REMOVE_TRANSITIVE_INCLUDES.

Please also refer to the discussions in include-what-you-use/include-what-you-use#1344, include-what-you-use/include-what-you-use#1536 as well as referenced PRs (among others).

[H-Wadman]

I see, my bad! I usually use cppreference as a go to, as I have not paid for the standard. I did however find this committee draft, and unless I am mistaken it seems as <string.h> does indeed provide NULL. Here is what it says:

The header <string.h> declares one type and several functions, and defines one macro useful
for manipulating arrays of character type and other objects treated as arrays of character type.
The type is size_t and the macro is NULL (both described in 7.19).

Even the wording for the <stddef.h> section seems to affirm this:

The header <stddef.h> defines the following macros and declares the following types. Some are
also defined in other headers, as noted in their respective subclauses.

Of course I might be misinterpreting the wording, but my first reading of this is that the NULL definitions in <stddef.h> and <string.h> are of similar rank. In fact neither of my Apple provided header, nor the LLVM header define NULL directly in <stddef.h>. Instead they are defined in <sys/_types/_null.h> and <__stddef_null.h> respectively, who are subsequently included into <stddef.h>. Therefore I am assuming misc-include-cleaner already has some knowledge of the standard (or interprets files with preceding underscores differently, but then <string.h> shouldn't get flagged). Hopefully this should mean adding other standard library headers as well as their corresponding definitions, should be less cumbersome.

[firewave]

I see, my bad! I usually use cppreference as a go to, as I have not paid for the standard. I did however find this committee draft, and unless I am mistaken it seems as <string.h> does indeed provide NULL.

I was talking in general regarding the publicly available documentation of the standards... and possibly to kickstart the discussion about this in another context. Sorry for bandwagoning on your most likely valid issue.