https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
--- Comment #18 from Alejandro Colomar ---
(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 weir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
--- Comment #17 from Alejandro Colomar ---
(In reply to Eric Gallager from comment #16)
> I'd just like to restate my preference for using separate named options
> instead of numerical warning levels. Brainstorming some ideas for potential
> nam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
--- Comment #15 from Vincent Lefèvre ---
(In reply to Vincent Lefèvre from comment #14)
> (In reply to Jakub Jelinek from comment #4)
> > If you want to compare against all ones time_t, just use ~(time_t)0 or
> > similar.
>
> This one is a bad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
--- Comment #14 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #4)
> If you want to compare against all ones time_t, just use ~(time_t)0 or
> similar.
This one is a bad idea as it may have issues with signed types (when not in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
--- Comment #13 from Alejandro Colomar ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
--- Comment #12 from Paul Eggert ---
On 2/26/25 07:29, vincent-gcc at vinc17 dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
>
> --- Comment #11 from Vincent Lefèvre ---
> (In reply to Alejandro Colomar from comment #10)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
--- Comment #11 from Vincent Lefèvre ---
(In reply to Alejandro Colomar from comment #10)
[about i + 1 == 0 instead of i == -1]
> But this causes readability issues. For error-handling, programmers are
> used to writing ==-1, and doing +1==0 wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
--- Comment #10 from Alejandro Colomar ---
(In reply to Vincent Lefèvre from comment #9)
> (In reply to Paul Eggert from comment #8)
> > (In reply to Jakub Jelinek from comment #4)
> > > just use ~(time_t)0 or similar.
> > That has a cast, and p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
Paul Eggert changed:
What|Removed |Added
CC||eggert at gnu dot org
--- Comment #8 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
--- Comment #7 from Alejandro Colomar ---
(In reply to Jonathan Wakely from comment #6)
> Not warning at all for a literal -1 seems reasonable to me. It's such a
> common idiom to compare to -1 for error checks.
>
> So suppress the warning only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
--- Comment #6 from Jonathan Wakely ---
Not warning at all for a literal -1 seems reasonable to me. It's such a common
idiom to compare to -1 for error checks.
So suppress the warning only for the literal -1 (and no other spellings, such
as -1L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
--- Comment #5 from Alejandro Colomar ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to Alejandro Colomar from comment #3)
> > unsigned long == -1 does The Right Thing(tm). The -1 is first
> > sign-extended, and afterwards converte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
--- Comment #3 from Alejandro Colomar ---
(In reply to Richard Biener from comment #2)
> Your point that unsigned long == -1 vs. unsigned long == -1u is not the same
> is a very good point to continue diagnosing this.
But the bug is actually in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
--- Comment #2 from Richard Biener ---
Your point that unsigned long == -1 vs. unsigned long == -1u is not the same
is a very good point to continue diagnosing this.
Now, for equality compares of operands of different sign but same precision
we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
--- Comment #1 from Alejandro Colomar ---
Or maybe we can just make -Wsign-compare not warn on that, without adding
levels at all.
18 matches
Mail list logo
