Tested on llvm codebase.
It have found many places like:
- returning true/false in function returning int,
- assigning true/false to integer inside some classes.
Prazek on Apr 6 2016, 3:28 AM.Authored by
Maybe we should merge it with http://reviews.llvm.org/D18745 and name it 'modernize-wrong-literal-cast'. The other question is, will it be better to move it to readability?
This check throws a warning also on the conversion to floats (probably very rare ones):
double number = true;
Even though this behavior is correct, the code warns about the implicit conversion to integers.
Actually, did you think about adding this as a clang diagnostic?
Richard, what do you think about complaining in Clang about int i = true; kind of code?
BTW, why is the check in the 'modernize' module? It doesn't seem to make anything more modern. I would guess, the pattern it detects is most likely to result from a programming error. Also, the fix, though it retains the behavior, has a high chance to be incorrect. Can you share the results of running this check on LLVM? At least, how many problems it found and how many times the suggested fix was correct.
I'd suggest to move the check to misc or maybe it's time to create a separate directory for checks targeting various bug-prone patterns.
There were many places. Most of them where when assigning true/false to some member which was int.
Would be nice, if you could tell the number and provide a list of locations. Have any of these been fixed since then?
No, I didn't know that I can do that - I always heard that I can't format code that I didn't change, so I though the same thing is here. I will try do post review of changes in clang/llvm soon.
I will think name for new module that would have all the checks like this.
Do you have any thought about the name for such a module? I belive that misc is overloaded.
So for this we are looking for something that is probably not a bug, but it makes code a little bit inaccurate
I would like to see a new version of http://reviews.llvm.org/D19105 with all the "1-bit-bitfield" diffs removed.
Do you have an example of a large codebase where this check runs with few false positives and a non-zero number of true positives?
I will post fixex tomorrow. I don't think there will be any false or true positives in warnings, but the main problems with fixes are that many times developer wants to use bools, but it decalres field/return type as int.
after a long though I think that "accuracy" is the best name here - we want to look for a code that is valid, but not accurate
There are many possible reasons this pattern can appear in the code. Sometimes it's a bug, sometimes, it's an attempt to make the code look better than it is ;) It seems to me though, that having a type mismatch of this kind is a bug-prone pattern, so I would start a more generic "bugprone" category of checks (and move some misc- checks there later on).
Also, please re-upload D19105 after disabling matches on 1-bit bitfields in the check.
It seems that it works right now.
I will update the llvm/clang changes today.
+Fixed bug with operators
I will post changes on clang tomorrow
Sorry for the delay. Your patch was lost in my inbox. Feel free to ping me earlier.