I think the code would be more readable if the functions in test/testcondition.cpp would have names corresponding to the implementations in lib/checkcondition.cpp.

I agree. I would like if we always used the same name.

I want to avoid copy paste. so basically the compact is better.

I would recommend that we reorder the code:

if (Token::Match(tok, "==|!=")) {
    ... keep the existing code ...
} else if (expr1->str() == "&") {
    // check < <= => > ...
} else if (expr1->str() == "|") {
    // check < <= => > ...
}

there are a few duplicated newlines in lib/checkcondition.cpp (l.42, l.201,l.396 ...). Should I remove them within the same PullRequest ?

thanks. it would not be totally wrong. but I think I prefer that you don't do it here. those lines are not near your changes.

I like that you try to see if there is an opportunity to cleanup the code.

since I am still not sure if binary operations on signed variables are safe and justified could you please give some use examples in real code ? I use binary ops mostly for reading registers in embedded world, and even ">,>=,<,<=" comparisons are strange in this area.

I agree it's strange with negative values. I would feel 99% confident about saying that (i|7>0) is always true even though i is signed. Off the top of my head I can't give a example in real code where negative values are used in bitoperations.

I also agree that ">,>=,<,<=" are strange.

My consideration is "Expression '(X & 0x0) == 0x0' is always true", and "Expression '(X | max(X)) == max(X)' is always true for unsigned X". Is there any way to check max(X) ?

I hope we don't warn about '(X | max(X)) == max(X)'. Consider:

void f(unsigned int x) {
    if ((X | 0xFFFF) == 0xFFFF) {}
}

That is always true on a 16-bit platform. But I think we should assume the code is portable and might be executed on other platforms also.

It looks pretty good now.

I am thinking about splitting the tests into three test functions. the checker checks "==|!=", "&" and "|" separately. so we could have separate test functions for those. what do you think?

I am not sure about splitting test functions. It will brake the concept of same names for checker/test function names. Secondly comparison function is for huge in my opinion.

But, you are the boss ;) I can split it by for example:
comparison_equal_not_equal()
comparison_or()
comparison_and()

Thanks! I applied this with 09a83f2. I think splitting the testfunction is optional, it's not required.