Re: [PATCH -mm] sys_semctl gcc 4.1 warning fix

[Steven Rostedt]

On Thu, 11 May 2006, Al Viro wrote:

>
> FWIW, I've got mostly finished pile of scripts (still needs to be
> consolidated, with merge into git for some parts) that does that following:
> take two trees and build log for the first one; generate remapped log
> with all lines of form <filename>:<line number>:<text> modified.  If line
> in question survives in the new tree, turn it into
> N:<new filename>:<new line number>:<text>
> with new filename and line giving its new location, otherwise turn it into
> O:<filename>:<line number>:<text>

And FWIW, not everyone has your scripts or the time to use them. The
init_self(x) thinging (and yes I hate that name) can be made to be a
compile time option.  So for those that are writing code, and only want to
look at the warnings that effect them, they have an option to turn off the
warnings of others (marked as false positives only). Heck, make the false
positives on as the default, and let others turn it off when developing.

I am one that spent several hours debugging my code, looking for a bug
that was caused by an "uninitialized variable".  The problem was, that I
became so damn use to ignoring those warnings, that I ignored them in my
own code.  I'm now a little more careful, but it still takes more time to
notice if those warnings are in code that I changed, or not.


>
> That reduces the size of diff between build logs a _lot_ - basically,
> all noise from changed line numbers is gone and we are left with real
> changes.  It works better with git (we catch renames that way), but
> even starting with diff between the trees works fairly well.
>
> IME, it makes watching for regressions quite simple, even when dealing with
> something like 2.6.16-rc2 and current, with shitloads of changes in between.
> And yes, I _do_ watch ia64 tree, with all its noise.  Moreover, I watch
> CHECK_ENDIAN sparse builds, aka thousands of warnings all over the tree...
>
> I'll get that stuff into sane form and post it; IMO it solves the noise
> problem just fine.

And IMO it solves it for you.  Not for everyone else.  Really, the only
argument that I see you have is the ugliness of the macro.  Since it can
be made configureable whether or not it disables those warnings, it
shouldn't affect you in any other way.  But it will really help those that
want to skip those warnings while looking at the compile output of their
code while they are developing it.

-- Steve

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/