2003-05-04 21:10:29

by Art Haas

[permalink] [raw]
Subject: Latest GCC-3.3 is much quieter about sign/unsigned comparisons

Hi.

This change ...

2003-05-02 Zack Weinberg <[email protected]>

PR c/10604
* c-opts.c (c_common_decode_option <OPT_Wall>): Set
warn_sign_compare for C++ only.
* doc/invoke.texi: Clarify documentation of -Wsign-compare.

... has eliminated all the warnings that GCC-3.3 by default printed
with regards to signed/unsigned comparisons. A build of today's BK
with this compiler is much quieter than those previously done
with the 3.3 snapshots.

Art Haas
--
To announce that there must be no criticism of the President, or that we
are to stand by the President, right or wrong, is not only unpatriotic
and servile, but is morally treasonable to the American public.
-- Theodore Roosevelt, Kansas City Star, 1918


2003-05-05 06:10:40

by Anders Karlsson

[permalink] [raw]
Subject: Re: Latest GCC-3.3 is much quieter about sign/unsigned comparisons

Hello there, :-)

On Sun, 2003-05-04 at 22:22, Art Haas wrote:
> Hi.
>
> This change ...
>
> 2003-05-02 Zack Weinberg <[email protected]>
>
> PR c/10604
> * c-opts.c (c_common_decode_option <OPT_Wall>): Set
> warn_sign_compare for C++ only.
> * doc/invoke.texi: Clarify documentation of -Wsign-compare.
>
> ... has eliminated all the warnings that GCC-3.3 by default printed
> with regards to signed/unsigned comparisons. A build of today's BK
> with this compiler is much quieter than those previously done
> with the 3.3 snapshots.

Yes, it means the warnings are not printed, it doesn't mean the problem
has gone away though.

I'd still like for someone to tell me if there is a specific reason to
use signed numbers in for example inode.c in one of the filesystems
(can't remember which one of the top of my head). I for one would get
rather surprised if some of my data started getting stored with negative
inodes...

Regards,

/Anders


Attachments:
signature.asc (198.00 B)
This is a digitally signed message part

2003-05-05 07:35:37

by Tomas Szepe

[permalink] [raw]
Subject: Re: Latest GCC-3.3 is much quieter about sign/unsigned comparisons

> [[email protected]]
>
> ... has eliminated all the warnings that GCC-3.3 by default printed
> with regards to signed/unsigned comparisons. A build of today's BK
> with this compiler is much quieter than those previously done
> with the 3.3 snapshots.

Is this a good thing, though? I'm quite sure those warnings were useful.

--
Tomas Szepe <[email protected]>

2003-05-05 12:55:10

by Dave Jones

[permalink] [raw]
Subject: Re: Latest GCC-3.3 is much quieter about sign/unsigned comparisons

On Mon, May 05, 2003 at 09:48:04AM +0200, Tomas Szepe wrote:
> > ... has eliminated all the warnings that GCC-3.3 by default printed
> > with regards to signed/unsigned comparisons. A build of today's BK
> > with this compiler is much quieter than those previously done
> > with the 3.3 snapshots.
>
> Is this a good thing, though? I'm quite sure those warnings were useful.

In a lot of cases, they were just noise. They are still there with
-W if you really want to see them.

Dave

2003-05-05 14:08:03

by Jörn Engel

[permalink] [raw]
Subject: Re: Latest GCC-3.3 is much quieter about sign/unsigned comparisons

On Mon, 5 May 2003 07:23:01 +0100, Anders Karlsson wrote:
> On Sun, 2003-05-04 at 22:22, Art Haas wrote:
> > This change ...
> > ... has eliminated all the warnings that GCC-3.3 by default printed
> > with regards to signed/unsigned comparisons. A build of today's BK
> > with this compiler is much quieter than those previously done
> > with the 3.3 snapshots.
>
> Yes, it means the warnings are not printed, it doesn't mean the problem
> has gone away though.

Which one do you mean? The real signed-unsigned bugs in the kernel or
the problem of gcc to weed out the false positives.

"find /usr/src/linux -type f | xargs cat" will catch every single bug
in the linux kernel, but I bet it won't get too many fixed. Those gcc
warnings are a bit better, but just a bit.

> I'd still like for someone to tell me if there is a specific reason to
> use signed numbers in for example inode.c in one of the filesystems
> (can't remember which one of the top of my head). I for one would get
> rather surprised if some of my data started getting stored with negative
> inodes...

If you manually seperate false positives from real bugs, then those
real ones should get fixed. Feel free to bombard me with any, but try
to keep the ratio of false positives low.

J?rn

--
"Translations are and will always be problematic. They inflict violence
upon two languages." (translation from German)