[M3devel] Modula-3/C interop in Date/Time?

[Jay K]

Rodney, right, I was wondering about traced vs. untraced also. I think having a traced pointer point outside the traced heap is ok though. The data will never be collected, the pointer never updated. If the untraced data were ever freed (such as e.g. unloading the .dll! Which people usually forget about as a scenario..) then the traced pointers would go stale and there'd be a safety problem.

 

 

In either case I'm not "rewriting" it, because there is a "unified interface" between Posix and Win32, and I can't make it <*external*> in one but not the other, unless I fork the file, not particularly worthwhile.

 

 

 - Jay

 
> Date: Thu, 15 Apr 2010 17:44:07 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Modula-3/C interop in Date/Time?
> 
> Since these pointer variables are initialized by
> C code and their referents are also provided by C code
> as global variables, shouldn't the type be untraced?
> 
> I suppose that, since they don't point into the traced
> heap, the collector implementation we have would quietly
> ignore them as roots. But that's relying on implementation-
> dependent information.
> 
> Also, if someone created a field of type Date.TimeZone,
> (or an array of them) in a traced-heap-allocated object,
> which is a perfectly legitimate thing to do, what would
> our collector do then?
> 
> 
> 
> Jay K wrote:
> > Is this legal/correct?
> > 
> > 
> > Date.i3:
> > TYPE TimeZone <: REFANY;
> > VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *)
> > 
> > 
> > Date.m3:　
> > REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER;
> > 　
> > 
> > DatePosixC.c:
> > static const int Local = 0;
> > static const int UTC = 1;
> > extern const int const * const Date__Local = &Local;
> > extern const int const * const Date__UTC = &UTC;
> > 　
> > 
> > - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100415/c1795b07/attachment-0002.html>