Re: Uninitialized "out" parameters

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

bobduff@world.std.com (Robert A Duff) writes:
>In article <4t1s3n$chv@goanna.cs.rmit.edu.au>,
>Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote:
>>In my experience of marking student C programs, trying to use uninitialised
>>variables is the commonest non-syntactic error.

>This doesn't necessarily indicate a need for compile-time checks.  It
>indicates a need for something -- possibly compile-time, possibly
>run-time, possibly some mixture.  And you get the usual trade-offs among
>efficiency, early error detection, and flexibility.

Bob Duff is the last person I would have expected to argue against static
checks.  Roughly the third most frightening thing I have seen in a computer
manual is the advice
	"If your program is halting with range-checking errors,
	 and you don't want to address those problems immediately,
	 you can always omit the {$R+} compiler directive
	 [thus suppressing the range checks] for the time being."
to be found in the Turbo Pascal 5.0 User Guide on p207.

If I can get a compile-time error (when it is provable that an uninitialised
variable will be used) or warning (when it is not provable that it won't),
why *not*?  In computing, ignorance is bliss.  Run-time checks only tell
you whether the path followed *this time* through the code encountered an
uninitialised variable or not.  One of the things we are trying hard to
teach is "just because your program didn't crash on YOUR test cases doesn't
mean it won't crash on OURS", and relying too much on run-time checks would
tend to exacerbate the problem.

As things stand, I *do* have ready access to tools that do *some* static
uninitialised variable checking for C:  lint, gcc -O2 -Wall, and lclint.
I would of course like to have ready access, at a price suitable for a
not-very-rich university whose government is talking about 10% cuts to
education funding, to run-time checks for C, and to similar compile time
and run time checks for Ada.

>>...  I have found the program
>>'lclint' _extremely_ useful when marking because it does a very good job of
>>noticing possible uninitialised variables.

>So why don't your students use lclint?

To be really honest, because I didn't tell them about it.
I *love* lclint, but it is a free system with a one-mand-and-his-dog
maintenance team, and it tends to have trouble with system headers
(sometimes because they are extremely non-standard C, sometimes because
they are standard but c****y C, sometimes because lclint needs improving)
and it produces a *LOT* of messages.  I have the background and patience
to work through long lists of messages and to work around the occasional
failure of the tool, the students don't.

On the other hand, they *are* told about lint, and they still don't use
that.  Heck, in the last assignment, a couple of students handed in C++
and I don't mean just C-with-//-comments (nor do I mean that it took
*advantage* of C++, just happened to be different enough not to be even
close to compiling under C).

If it comes to that, they are also told to compile with gcc, and I even
gave them a shell script to use that set -O2 -Wall, and they didn't do
that either.

What this leads up to is that a compiler for *student* use needs to have
a high level of static checking switched *by default*.
-- 
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.