rL310669 is the latest and complete version. It fixes an issue in windows platform.
Aug 11 2017
Aug 10 2017
Show full context.
Aug 9 2017
Aug 7 2017
Looks good to me, a few nits. Thanks for improving it continuously.
I'd hold it for a while to see whether @alexfh has further comments before submitting it.
Aug 4 2017
Aug 3 2017
Aug 1 2017
Move tests to unitest and fix a bug.
Jul 31 2017
Jul 28 2017
Jul 27 2017
Add more tests and restrict the conditions.
Jul 26 2017
Add more tests.
Including cases 'attribute((packed, aligned(X)));'. When the alignment before packing is less or equal to the packed one, he 'packed' attribute not including 'aligned(X)' seems unnecessary. Because the alignment won't change as well as the size after removing 'packed'.
Some concrete suggestions throughout the patch, but I think we should take a step back and reconsider this warning approach: it seems bizarre for us to warn on any packed struct that happens to contain a char. It would make sense to warn if an __attribute__((packed)) written in the source has *no* effect (because it's applied to a struct where all fields already have alignment 1, or because it's applied to a field that has alignment 1) -- even then I'm not entirely convinced this is a valuable warning, but I assume there's some reason you want to warn on it :)
Change the condition of this unnecessary packed warning to when the alignment of the class is one byte. Remove all field-level warning.
Jul 24 2017
Jul 21 2017
Jul 20 2017
Refactor the check, add a base class for it, which can facilitate all other similar checks. Basically, all checks in the same category will have only one or two lines code in both "check" and "registerMatcher" by inheriting the base class. If this looks good, I will modify all other similar ones. Thank you :-)
Jul 17 2017
I have deja vu ;)
Should we make a single check for all CLOEXEC and friends with a single configurable list of (function name, flag name) pairs?
Okay, it may be a bit more complicated than just a list of function name -> flag name mappings, since we have to take in account the argument position as well. We also might want to check the signature to a certain degree to avoid matching wrong function. There are multiple approaches possible to rule out incorrect functions with the same name:
- just look at the number of arguments - this might well be enough, since for a certain codebase I wouldn't expect multiple memfd_create's etc. It would allow user configurability of the function -> flag mappings.
- encode the types of arguments as strings and have a small dictionary of matchers in the check (e.g. "const char*" -> pointerType(pointee(isAnyCharacter()))) - that will be more precise and still quite flexible and also allow user-configurable function -> flag mappings. But this mechanism may be an overkill, if we don't anticipate user-configurable functions. I don't know how complex the resulting code turns out to be.
- Add a matcher for each function statically. This would obviously allow for arbitrarily complex matchers, but won't be extensible via configuration options.
Jul 13 2017
Jul 12 2017
Jul 11 2017
Jul 10 2017
LGTM. Please wait for Alexander approval.
Jul 5 2017
Jun 30 2017
Jun 29 2017
Change the file name in toctree.
Pull back the previous change. For some reason it's lost.