Re: Uninitialized "out" parameters

[bobduff@world.std.com (Robert A Duff)]

In article <4t4r0s$8te@goanna.cs.rmit.edu.au>,
Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote:
>Bob Duff is the last person I would have expected to argue against static
>checks.

I'm not sure why it surprises you -- after all, I had a hand in writing
an RM that has more run-time checks than you can shake a stick at.  ;-)

Anyway, the decision between compile-time and run-time checking is
always a trade off between safety and flexibility (among other things).
Whenever you check something at compile time, the check is necessarily
stricter than it needs to be -- the halting theorem tells us that.

Consider the case of divide-by-zero.  We could easily catch all
divides-by-zero at compile time, if we're willing to be overly
conservative.  However, this would make the language a lot less useful.

>...  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.

Wow.  That is indeed amazingly bad advice.

>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*? ...

I certainly agree with the first part (just like I want the compiler to
complain if it *knows* I'm going to divide by zero).  But the second
part is questionable.  It means I'm going to get a lot of spurious
warnings, since my programs typically contain lots of pointers to
heap-allocated records, and it's not feasible for a compiler to do a
very good job for that kind of data.  So what do I do with all those
warnings?  Well, I can ignore them, but that's horrible, because every
time I recompile something, I will keep getting the same stupid warnings
-- the compiler is to stupid to realize that I've already analyzed those
particular warnings, and satisfied myself that they're bogus.  So if
there's ever a *correct* warning, I'll probably miss it.  So, instead,
what I have to do is add in some junk code that makes the compiler shut
up.  For example, I'd probably have to default-initialize every record
component, whether it needs it or not.

Note that in this case, run-time checks will probably find more bugs
than compile-time checks.  This is because I added in all those bogus
initializations to some nonsense value.  So if I do have a bug, I'll get
that nonsense value, and perhaps get a wrong answer.  (At least it will
be the *same* wrong answer every time!)  Whereas if the checking were
done at run time, I would get an exception.  (And of course I understand
that I might fail to test that execution path, which is the problem with
run-time checking.)

Of course, with most Ada compilers, I don't get run-time checks, and I
may or may not get compile-time warnings in some small subset of the
cases.

Anyway, I don't believe compile time checking is always better than run
time checking.  It's a trade-off, and the language designer has to
consider the details of each case.  The compiler writer, too, for
deciding what warnings to produce.

>What this leads up to is that a compiler for *student* use needs to have
>a high level of static checking switched *by default*.

Probably a good idea.

- Bob