On Wed, May 10, 2006 at 04:45:54PM -0700, Andrew Morton wrote:
> Al Viro <[email protected]> wrote:
> >
> > On Wed, May 10, 2006 at 04:05:48PM -0700, Andrew Morton wrote:
> > > Sure - it's sad and we need some workaround.
> > >
> > > The init_self() thingy seemed reasonable to me - it shuts up the warning
> > > and has no runtime cost. What we could perhaps do is to make
> > >
> > > #define init_self(x) (x = x)
> > >
> > > only if the problematic gcc versions are detected. Later, if/when gcc gets
> > > fixed up, we use
> >
> > Sorry, no - it shuts up too much. Look, there are two kinds of warnings
> > here. "May be used" and "is used". This stuff shuts both. And unlike
> > "may be used", "is used" has fairly high S/N ratio.
> >
> > Moreover, once you do that, you lose all future "is used" warnings on
> > that variable. So your ability to catch future bugs is decreased, not
> > increased.
>
> Only for certain gcc versions. Other people use other versions, so it'll
> be noticed. If/when gcc gets fixed, more and more people will see the real
> warnings.
>
> Look, of course it has problems. But the current build has problems too.
> It's a question of which problem is worse..
We could turn of this kind of warnings that generate these kind of false
positives globally with -Wno-uninitialized until a future gcc version
might be better at avoiding false positives.
But there's one problem, this turns off two kinds of warnings:
- 'foo' may be used uninitialized in this function
- 'foo' is used uninitialized in this function
The first kind of warnings is the one generating the false positives
while the second kind are warnings we do not want to lose, but AFAIK
there's no way to only turn off the first kind.
Perhaps asking the gcc developers for separate options for these two
kinds of warnings in gcc 4.2 and then turning off the first kind is
the way to go?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
