Jonathan S. Shapiro wrote:
> As we contemplate an s-block syntax for BitC, one question that emerges
> is initialization rules. In particular, BitC really wants to require
> that pointer slots (a) be initialized, and (b) be non-null.
>
> In the lispish surface syntax this doesn't feel awkward, but in an
> s-block surface syntax we will soon want to introduce something like a
> constructor, and we will then get into situations where we say "field p
> must be a non-null pointer to a mumble", but field p will not be
> initialized at the first line of the constructor.
>
>>From a safety perspective, I believe that the following constraints are
> sufficient to ensure safety:
>
> 1. Field p must be properly initialized to a non-null pointer
> before it is used.
>
> 2. The object pointer must not escape from the constructor
> until all such type safety constraints are satisified.
> In particular this constrains exception values.
> First, does everyone agree that these conditions are sufficient?
>
> Second, do we believe that we can specify an algorithm for checking this
> property so that it can be statically determined at source level whether
> a program is well-formed w.r.t. type safety?
Is the condition is same as saying `p' must never be used as an
rvalue before being initialized? This condition is certainly sufficient.
The checking algorithm can be simple or complex based on how "visibly" p
is initialized.
That is, p could be initialized by:
i) Straight line code before use (trivial to check).
ii) Initialized differently in different branches of conditionals (this
is also easy to check, but I am not sure if it is necessary in a
constructor).
iii) p might be passed by reference (note that this is not really an
rvalue usage) to another function that initializes it. (this is
hard to check in general).
Swaroop.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
