Re: Uninitialized "out" parameters

[ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe)]

bobduff@world.std.com (Robert A Duff) writes:
>With regard to uninit vars, the compiler can categorize each variable
>reference as one of (1) correct, (2) wrong, or (3) don't know.

>Clearly, the compiler should warn for (2), not warn for (1).  But what
>should it do for (3)?

Leave it to the programmer.  Let it be Options|Compiler|PossibleUninit|On
or whatever.  At least make it _available_.

For what it's worth, whenever Lint has given me a bogus warning, the code
in question has been so warped that it has warranted a rewrite anyway.
The same goes double with lclint.  If you really truly believe that
programs should be written to be maintainable, then the slogan
"not no obvious errors, but obviously no errors" means that it shouldn't
be hard for a programmer or a compiler to see that the code is right.
That means treating "I can't tell whether this is initialised or not"
messages as warnings that the code is hard to understand.

Both lint and lclint offer the choice of
 - globally suppressing such messages from the command line
 - locally annotating a fragment of code to say that a certain
   warning should be suppressed (in fact, lclint will, if asked,
   warning if the expected number of warnings _isn't_ suppressed,
   so that suppressions obsoleted by code changes don't go unnoticed).
The latter leaves a visible warning to maintainers in the source code:
"something funny is going on here, but trust me".

-- 
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.