On Wed, 2008-01-23 at 21:07 +0000, Sam Mason wrote: > On Wed, Jan 23, 2008 at 02:28:36PM -0500, Jonathan S. Shapiro wrote: > > On Wed, 2008-01-23 at 19:22 +0000, Sam Mason wrote: > > > > > 1. Field p must be properly initialized to a non-null pointer > > > > > before it is used. > > > > > > Do null pointers ever get exposed to the user? I believe Optional/Maybe > > > types are to be implmented as null values, but that's not quite the same > > > in my mind. > > > > Not today. > > I'm still struggling to understand the "non-null pointer" requirement > pointers are well in concrete implementation land for me. "ref"s can't > be null can they (and changing that would probably break a lot of code)? > "optional ref"s can have a "none" value though
Your statements about refs are correct. The problem is that with C-style initialization syntax, there can be windows of time where a non-null REF field hasn't yet been initialized. Under these conditions, the compiler/runtime has nullified it in order to avoid offending the GC system, but it's not legal to reference it until after it has been properly initialized to an object reference. > so the initialisation you're talking about is wholly for type safety, GC > correctness would be ensured by sometimes initialising things twice (i.e. > once where the code actually does the initialisation and the other before > as part of object allocation or some such)? Yes. In abstract, that's already true today. The only reason we don't have to explicitly nullify an object today is that the BitC constructor syntax statically guarantees that no call to GC can happen in between the call to the constructor and the return from the constructor (by which point the object is fully initialized). > > > I've just reread the message and noticed that your comments were really > > > aimed at structures, does that mean you're only worried about the heap > > > at the moment? > > > > Also stack allocated cases. In BitC, a structure can be a value type. > > Again I'm using terms incorrectly, I was trying to ask about how the > initialisation of non-composite objects are tracked. I've thought about > it some more and realised that it's a small sub-case automatically > handled by Swaroop's definition. Yep. Or here is another way to think about it: there is no such beast. Any local variable is part of an (implicit) compound object that is the stack frame of the current procedure. Any global variable is part of an (implicit) compound object that constitutes the global program state. In fact, we already have initialization ordering rules for globals to ensure that things are initialized before use. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
