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 > But as we move to an s-block syntax, we will want to adopt a > more C-like idiom for initialization. ... > And the equivalence can be determined in most real use-cases by static > analysis. In the interests of idiomatic compatibility, it would be > pleasant if we could handle this some day. OK > > > Is the condition is same as saying `p' must never be used as an > > > rvalue before being initialized? This condition is certainly sufficient. > > > > How well does this interact with garbage collection? It seems as > > though you're going to have things on the stack that are known to be > > uninitalised pointers. Can these be flagged to the garbage collector, > > or is the current frame special somehow? > > The implementation must quasi-initialize such fields to zero to ensure > GC safety, but that since the data structure isn't well-typed until it > is more or less fully initialized, this doesn't really create a problem > for typing. 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)? > > 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. Sam _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
