named warnings & individual warning control

[Stan Shebs]

Joe Buck wrote:

>On Fri, Jun 25, 2004 at 04:02:19PM -0700, Stan Shebs wrote:
>
>>So if I understand what you're getting at, it would be to have some
>>weaker form of flow analysis in the front end to implement the
>>uninitialized warnings, even if that means reporting some false
>>positives? I can go for that; if it takes a complicated analysis to
>>determine that a variable really is initialized before use, there's a
>>good chance that the code is only working correctly by accident, and
>>that minor changes - say, just before going into production use, per
>>Murphy - would break it.
>>
>
>Not really.  The most common false positive for uninitialized variable
>warnings takes this form:
>
>    T* ptr_T;
>    bool ptr_is_valid = false;
>    if (some_fancy_test()) {
>	ptr_T = foo();
>	ptr_is_valid = true;
>    }
>    do_something_else();
>    if (ptr_is_valid) {
>	do_something_with(ptr_T);
>    }
>
Two answers come to mind:

    T* ptr_T = NULL;

If this default initialization is provably unnecessary, then it
will be removed, right? If it's not redundant, then a good thing
it was there. This will take some user education before they will
believe it gets removed.

Or,

    T* ptr_T __attribute__((I_know_what_Im_doing));

to suppress the warning selectively, if the user absolutely
must make it go away.

The second doesn't preclude the first of course.

Stan

(now off to see Fahrenheit 9/11! Keeping priorities straight :-) )