[bitc-dev] A curious question
swaroop at cs.jhu.edu
Wed Jan 23 11:58:53 EST 2008
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
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
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).
More information about the bitc-dev