On Wed, 10 May 2006, Daniel Walker wrote:
>
> There's no code increase when you init something to itself . I could
> convert all the instance of the warning, that I've investigated, to a
> system like this . I think it would be a benefit so we could clearly
> identify any new warnings added over time, and quiet the ones we know
> aren't real errors .
>
> However, from all the responses I'd imagine a patch like this wouldn't
> get accepted ..
>
I really don't see why it couldn't be added. What's the problem with it?
I mean, I see lots of advantages, and really no disadvantages.
It can be done incrementally such that each change can be scrutinized to
make sure it really isn't a bug.
Once it is determined, not to be a bug, we add the macro to hide the
warning. That way we lower the noise of warnings and look for places that
do have bugs.
It is a marker to let those, as Alan Cox suggested, look at them once in a
while to see if they are not really bugs.
Think about it. If you get rid of all places that gcc incorrectly shows
something uninitialized, you can find the places that are truely bugs.
Once we get rid of all warnings, we can then turn off the macro to look
again to make sure none of them are problems.
The only disadvantage is that there's some macro wrapping a variable. But
hell, that even was one of the advantages. It's a marker that shows us
that gcc thinks it's not initialized properly.
And I already mentioned, that it wouldn't be too hard to see if any of the
marked variables no longer needs to be marked.
-- Steve
-
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]
