This is an archive of the discontinued LLVM Phabricator instance.

[clang-tidy] non-portable-integer-constant check
Needs ReviewPublic

Authored by ahmed on Oct 29 2020, 8:08 AM.

Details

Summary

According to
https://wiki.sei.cmu.edu/confluence/display/c/INT17-C.+Define+integer+constants+in+an+implementation-independent+manner

bugprone-non-portable-integer-constant check is created
The check finds masks that are being used in a non-portable manner.

Diff Detail

Event Timeline

ahmed created this revision.Oct 29 2020, 8:08 AM
ahmed requested review of this revision.Oct 29 2020, 8:08 AM
ahmed updated this revision to Diff 301634.Oct 29 2020, 8:33 AM

adding alias doc in ReleaseNotes.rst

ahmed updated this revision to Diff 301637.Oct 29 2020, 8:41 AM

fix alias doc

Eugene.Zelenko added inline comments.
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.

whisperity added inline comments.Jun 24 2021, 3:59 AM
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)

124

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)

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.

steakhal added inline comments.Jun 24 2021, 7:59 AM
clang-tools-extra/clang-tidy/bugprone/NonportableintegerconstantCheck.cpp
54

You are assigning a pointer to a temporal std::string. It will dangle.

58

There could be digit separator apostrophes. E.g.: 0x44'4'4.