Re: To Initialise or not

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

In article <3188AF51.1F1A7590@escmail.orl.mmc.com>,
Theodore E. Dennison <dennison@escmail.orl.mmc.com> wrote:
>Well, no. A compiler can't detect a thing at run-time. The compiler is
>not even running then. It is happily asleep on the disk, dreaming
>compiler dreams.

Yeah, yeah, yeah.  I meant that the code generated by the compiler can
do it.

>I do see what you are getting at, but I don't think adding a "dirty
>bit" to every varaible is a serious consideration. (At least, the
>systems programmer in me HOPES it isn't).

As I said, the argument against this is efficiency.  And, possibly, that
it might make interfacing to other languages or hardware more difficult.
(I can imagine ways to implement it invisibly.)

You don't have to add an entire bit, in most cases.  You need to add an
extra value, which will add an extra bit only if the type you're talking
about *exactly* uses up all the bit patterns.

Initializing all access types to "null" is pretty much the same
technique -- except it doesn't detect *reads* of null pointers, but just
*dereferences* of null pointers.  Does the "systems programmer in you"
find this ludicrously expensive?  It is, in fact, expensive, in some
cases.  For example, I recently profiled a program I wrote, and found
that it spent most of it's time initializing arrays-of-access to null
values!  On the other hand, it does detect some bugs.  For an integer
type that doesn't exactly match the hardware supported bounds (e.g. type
T is range 1..1_000_000), there's no need to add an extra bit.

I once used a Pascal compiler where type Integer was defined to be
-2**31..2**31, and the extra value -2**31-1 was used to detect
uninitialized variables.  This was quite useful.  If my program had been
too slow, I might have wanted a way to turn this feature off.  But it
wasn't.  Also, if my program had wanted to interface to the actual
hardware notion of a 32-bit integer, I might have wanted a way to turn
it off.

Run-time detection of uninitialized variables is useful, but has some
cost.  It seems to me that only the application programmer can
reasonably make this trade-off.  The cost is different, depending on
various properties of the application, and whether the cost is tolerable
also depends on the application.  (For a packed array of Booleans,
adding an extra "uninit" value *doubles* the size of the array!)

- Bob