Re: To Initialise or not

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

In article <31933B50.687D@lmtas.lmco.com>,
Ken Garlington  <garlingtonke@lmtas.lmco.com> wrote:
>I thought I was convinced by this, but on reflection...

>1. Are you converting _all_ access types to encoded integers, or just a
>particular _use_ of an access type? If the latter, then you can't do it
>completely mechanically (assuming more than one access type) for all
>occurences of null.  You still have to find the specific declarations
>that need to be modified. Since you have to do that anyway, you're
>really not gaining much by denoting them with an explicit null. Now, if
>you had a different name for null for each access type, this might
>work. Otherwise, I don't think you gain very much.

I imagined converting a particular access type, or perhaps a group of
related access types in a particular part of the program.  I didn't mean
I would replace all occurrences of ":= null" with ":= Null_Integer", or
whatever -- I realize you have to pay attention to what the types are.
And you'll search the particular parts of the program that deal with
this (those) type(s).

By the way, in many cases, I do indeed use a special name for null for
each access type.  I declare "No_Particular_Doctor: Doctor_Ptr := null;"
or something like that, and always use No_Particular_Doctor instead of
null.  (Same problem with any other coding convention -- if you don't
obey it, you'll end up with a mixture of No_Particular_Doctor and null,
causing confusion.)

>2. Assuming you really _are_ converting all access types to integers
>(or even if you're not, now that I think about it), you have a
>different problem. To retain your (presumably desired) behavior of an
>implicit null being used to catch errors, you also have to come up with
>some way to trap references to your uninitialized integers. This means
>you have to visit those declarations with the implicit null, and either
>assign them an out-of-range value (Null_Pointer, maybe?), or do
>something else. (You probably will also want to add the appropriate
>assertions in your code before you "dereference" the integers. However,
>even if you didn't add the code, the Null_Pointer assignment would
>still be useful for debugging purposes...)

No, I wouldn't do that.  I would rely on pragma Normalize_Scalars, or
else rely on the normal way of detecting uninitialized integers -- be
careful.

If I really did want to encode detection of the uninit integers in the
program, I would use a different value than the one meant to encode
"null".  To really get that right, you'll have to wrap the integer in a
record, since only records allow user-defined default initial values
(unfortunately).  And that might well be too much trouble.  It might
even introduce bugs, since access types and integers are always passed
by copy, whereas records might be passed by reference.

>3. Both of these actions (replacing the explicit null with
>Null_Pointer, and the implicit null with... Null_Pointer?!?) can be
>done mechanically (and with less human error, I suspect), without the
>explicit null - assuming you have a tool that does data flow analysis,
>or at least can track declaration/use information. In fact, the
>explicit null could actually reduce the effectiveness of such an
>analysis. I know that, particularly with older code that has been
>maintained by several parties, I would trust an automated analysis tool
>over your coding convention.

No such tool is going to do a decent job when it comes to heap data.

>So, I'm still not convinced.

Sorry.  ;-)

- Bob