https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
--- Comment #18 from Alejandro Colomar <alx at kernel dot org> ---
(In reply to Alejandro Colomar from comment #13)
> (In reply to Paul Eggert from comment #12)
> > Plus, i + 1 == 0 does not necessarily work if time_t is 'unsigned short'
> > (yes that'd be really weird for time_t, but ISO C and POSIX allow it and
> > I try to write to the standards, and the problem has come up with other
> > system types).
>
> ==-1 wouldn't work either for unsigned short. That's why we mentioned the
> requirement that the variable should be of a type with rank no less than int.
On the other hand, my own response shows that the requirement of the rank is
useless, because default promotions apply before this diagnostic even kicks in.
As my example quoted below shows, in case of an unsigned integer of rank lower
than int, we trigger -Wtype-limits, which is different.
So for this diagnostic, we could just avoid diagnosing for literal -1 always.
>
> With unsigned short, you first promote it to an int, since int can hold any
> value of unsigned short, and it holds a USHRT_MAX, which is a small-ish
> positive number, while -1 keeps being negative.
>
> alx@debian:~/tmp$ cat ushrt.c
> int
> main(void)
> {
> unsigned short uh = -1;
>
> if (uh == -1)
> return 0;
> return 1;
> }
> alx@debian:~/tmp$ gcc -Wall -Wextra ushrt.c
> ushrt.c: In function ‘main’:
> ushrt.c:6:16: warning: comparison is always false due to limited range of
> data type [-Wtype-limits]
> 6 | if (uh == -1)
> | ^~
> alx@debian:~/tmp$ ./a.out
> alx@debian:~/tmp$ echo $?
> 1
>
>
> Still, both working on the same cases, ==-1 is going to cause less mental
> surprises.
