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

[Jay K]

But then unsafe, right?

 - Jay

> From: hosking at cs.purdue.edu
> Date: Thu, 15 Apr 2010 22:06:14 -0400
> To: rodney_bates at lcwb.coop
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Modula-3/C interop in Date/Time?
> 
> Indeed!  UNTRACED.
> 
> 
> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote:
> 
> > 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/20100416/ffbc03e2/attachment-0002.html>