lkml.org 
[lkml]   [2006]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH -mm] sys_semctl gcc 4.1 warning fix

    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-05-11 10:13    [W:6.586 / U:0.232 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site