[cfe-dev] -Wsign-compare warns on different signs of operands for ?:

[John McCall]

On Jul 14, 2011, at 1:32 PM, Richard Trieu wrote:
> On Thu, Jul 14, 2011 at 1:11 PM, John McCall <rjmccall at apple.com> wrote:
> On Jul 14, 2011, at 12:58 PM, Richard Trieu wrote:
>> On Wed, Jul 13, 2011 at 10:08 PM, John McCall <rjmccall at apple.com> wrote:
>> 
>> On Jul 13, 2011, at 5:15 PM, Richard Trieu wrote:
>> 
>> > For code such as:
>> >
>> > void f(unsigned int u, int i) {
>> >   (void) (true ? u : i);
>> > }
>> >
>> > When run with -Wsign-compare, Clang gives the following warning.
>> >
>> > warning: operands of ? are integers of different signs:
>> >       'unsigned int' and 'int' [-Wsign-compare]
>> >   (void) (true ? u : i);
>> >                ^ ~   ~
>> >
>> > Yet, no comparison is going on between u and i, so the warning seems out of place for grouping with -Wsign-compare.  I think that it would be better is this warning was pulled out of the -Wsign-compare diagnostic group.  Also, gcc's -Wsign-compare does not warn on this code, so this change will make Clang's sign compare closer to gcc's.  Does this seem reasonable?
>> 
>> gcc's -Wsign-compare does warn on this code if you make the condition non-trivial.  Clang is just missing that special case.
>> 
>> John.
>> 
>> Could you give an example of a non-trivial case that gcc does warn on?  I've tried:
>> 
>> void f(bool b, unsigned int u, int i) {
>>   (void) (b ? u : i);
>> }
>> 
>> void f(unsigned int u, int i) {
>>   (void) ((i > 5) ? u : i);
>> }
>> 
>> but both don't give an warning from gcc -Wsign-compare.  Clang's -Wsign-compare warns on both.
> 
> Aha.  From 'bool' I take it that you're talking about C++.  You're correct that G++'s -Wsign-compare does not warn about conditional operators.  GCC's does.  In clang, we decided that that inconsistency wasn't worth emulating.
> 
> John.
> 
> Sorry for the confusion.  If we don't care about consistency in this case, can we remove this warning so that our -Wsign-compare will only be about signed comparisons?

I have no problem with that;  just don't tell me it's about consistency with what GCC does. :)

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110714/b473b153/attachment.html>