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

[Tony Hosking]

Why unsafe?  Depends what you do with it.

On 16 Apr 2010, at 00:24, Jay K wrote:

> 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,
> > ! 2; (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 D! ate__UTC = &UTC;
> > >> 　
> > >> 
> > >> - Jay
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100416/822f17f3/attachment-0002.html>