This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: named warnings & individual warning control


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 :-) )


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]