bugprone-non-portable-integer-constant check is created
The check finds masks that are being used in a non-portable manner.
Details
- Reviewers
aaron.ballman alexfh hokein njames93
Diff Detail
Event Timeline
clang-tools-extra/clang-tidy/bugprone/NonportableintegerconstantCheck.cpp | ||
---|---|---|
1 | Please make length 80 symbols. | |
25 | Unnecessary empty line. | |
45 | Unnecessary empty line. | |
49 | Unnecessary empty line. | |
71 | Please add newline. | |
clang-tools-extra/docs/ReleaseNotes.rst | ||
75 | Wrong symbol. | |
114 | Please use alphabetical order fore new checks entries. | |
122 | See previous release for such lines wrapping. | |
clang-tools-extra/docs/clang-tidy/checks/bugprone-non-portable-integer-constant.rst | ||
4 | Please make same length as title. | |
8 | Should be C/C++. See other documentation. | |
15 | Please add newline. | |
clang-tools-extra/docs/clang-tidy/checks/cert-int17-c.rst | ||
6 | Please make same length as title. |
Have you run this check over any large code bases to see just how often it triggers and whether the diagnostics are false positives or true positives? I have a sneaking suspicion that this will yield a *ton* of false positives and probably not a whole lot of true positives. For starters, the issue isn't really a bugprone one -- the recommendation is about the behavior when compiling for different architectures or with different compilers, so this is more of a portability issue. It may make sense to move this into the portability module instead. However, the other issue is: a lot of CERT recommendations are recommendations rather than rules because it's impossible to determine programmer intent from the source code. If the user is intentionally using these literals, how should they silence this diagnostic?
clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp | ||
---|---|---|
38 | Please use PascalCase for this -- NonPortableIntegerConstantCheck.h (be sure to change the actual case of the files being added in addition to the include directives) | |
clang-tools-extra/clang-tidy/bugprone/NonportableintegerconstantCheck.cpp | ||
41 | I'm a bit worried about the performance of this check given that it's going to make a function call on every single integer literal anywhere in the program. I'd be curious to know how this check performs compared to other checks in the bugprone module. | |
48 | No need to test for this -- the only way check() gets called is if your matcher matches, and you only bind one matcher node, so this will always be nonnull. Feel free to assert it if you want. | |
55 | Why only hex literals? Why not octal or binary literals, for instance? | |
64 | There's extra whitespace in the diagnostic that should be removed, but also, this doesn't really tell the user how the integer is being used in a non-portable manner. If I saw that diagnostic, I wouldn't know how to respond to it to correct the issue. | |
clang-tools-extra/clang-tidy/bugprone/NonportableintegerconstantCheck.h | ||
1 | When you update the file names, be sure to hit things like these comments too. | |
clang-tools-extra/docs/ReleaseNotes.rst | ||
75 | It looks like a whitespace change snuck in and can be removed. | |
clang-tools-extra/docs/clang-tidy/checks/bugprone-non-portable-integer-constant.rst | ||
6 | This needs a lot more explanation, and it should also link back to the CERT recommendation somewhere. |
clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp | ||
---|---|---|
38 |
| |
124 |
Not just for the filename, but for the class's name as well, everywhere. | |
clang-tools-extra/clang-tidy/bugprone/NonportableintegerconstantCheck.cpp | ||
21–23 | ||
24–38 | C++17 introduced binary literals, i.e. 0b00001100, which could also be used for masking operations. I suggest creating two functions isUnsafeHexMask() and isUnsafeBinMask() and a wrapper function that calls both(?), and supporting finding literals like 0b1000000000000000 and 0b1111111111111111. | |
30 | ||
41 | I did a quick skim and it seems there is plenty of integerLiteral( matches used here and there, but most of them seem to either do an equal(0) or equal(1) sub-matching first. If performance is a concern, I think we could do an unless(equal(0))-like construct, given that no pattern that we try to check may match a literal 0. (Although if we dig deeper into the maths, maybe we can come up with a better lower bound?) | |
63–64 | This message is misleading. It should emphasise that it looks like a bit mask, and given that the CERT rule suggests portable ways (-1 instead of 0xFFFF and ~(MAX >> 1) instead of 0x8000), this check should be able to produce FixIts based off of that. | |
clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp | ||
106–108 | This is a C-specific check, or does it apply to C++ too? If only applies to C, it should be disabled in C++ mode, if it applies to C++, is there a C++-specific CERT rule/tag/number/ID for that version? | |
clang-tools-extra/docs/ReleaseNotes.rst | ||
115–117 | The name of the check versus the one-liner summary doesn't really match up. |
Please use PascalCase for this -- NonPortableIntegerConstantCheck.h (be sure to change the actual case of the files being added in addition to the include directives)