lkml.org 
[lkml]   [2007]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: somebody dropped a (warning) bomb
    Date
    Linus Torvalds <torvalds@linux-foundation.org> writes:
    > On Thu, 15 Feb 2007, Sergei Organov wrote:
    >>
    >> I agree that if the warning has no true positives, it sucks. The problem
    >> is that somehow I doubt it has none. And the reasons for the doubt are:
    >
    > Why do you harp on "no true positives"?

    Because if somebody is capable to proof a warning has no true positives,
    I immediately agree it's useless. I just wanted to check if it's indeed
    the case. It seems it is not.

    > That's a pointless thing. You can make *any* warning have "true
    > positives". My personal favorite is the unconditional warning:
    >
    > warning: user is an idiot
    >
    > and I _guarantee_ you that it has a lot of true positives.

    Yes, but there is obviously 0 correlation between the warning and the
    user being an idiot (except that non-idiot will probably find a way to
    either turn this warning off, or filter it out).

    I already agreed that a warning may have true positives and still be
    bad; and a warning having "no false negatives" is obviously a pretty
    one, though unfortunately not that common in practice; and a warning
    that has no true positives is useless. What we are arguing about are
    intermediate cases that are most common in practice.

    As programmers, we in fact are interested in correlation between a
    warning and actual problem in the software, but for the kind of warnings
    we are discussing (sign-correctness and type-safety in general), the
    correlation depends on the style the program is written is, making it
    difficult to use as a criteria in the discussion.

    > It's the "no false negatives" angle you should look at.

    I'd like to, but then I'll need to classify most of (all?) the GCC
    warnings as bad, I'm afraid.

    > THAT is what matters. The reason we don't see a lot of warnings about
    > idiot users is not that people don't do stupid things, but that
    > *sometimes* they actually don't do something stupid.
    >
    > Yeah, I know, it's far-fetched, but still.
    >
    > In other words, you're barking up *exactly* the wrong tree. You're looking
    > at it the wrong way around.
    >
    > Think of it this way: in science, a theory is proven to be bad by a single
    > undeniable fact just showing that it's wrong.
    >
    > The same is largely true of a warning. If the warning sometimes happens
    > for code that is perfectly fine, the warning is bad.

    Consider:

    int find_first_zero(const int *a)
    {
    int index = 0;
    while(*a++ != 0)
    index++;
    return index;
    }

    unsigned int array[] = { 1, 2, 3, 0, 25, 14 };
    int index = find_first_zero(array); *WARNING*

    So, by your logic, -Wpointer-sign warning is bad in general? If not,
    then how will you "fix" the code above? And the upside of the fix is
    what?

    IMHO, the "problem" is that this warning is about violation of type
    safety. Type safety by itself doesn't guarantee the code is perfectly
    fine. Violation of type safety doesn't necessarily mean the code is
    broken. A warning that warns about violation of type safety has the same
    properties. Now, it's up to you to decide if you want warnings on type
    safety or not.

    What you are saying, on the other hand, for me reads like this: "I do
    want warnings on violations of type safety in general, except for
    "signed char" or "unsigned char" being used instead of "char"". I think
    I do understand your reasons, -- I just don't agree with them.

    -- Sergei.
    -
    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: 2007-02-19 15:01    [W:2.891 / U:0.080 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site