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

Fri Apr 16 09:00:34 CEST 2010

I don't think there's anything unsafe about UNTRACED.

It's DISPOSE that's unsafe...

    Mika

Jay K writes:
>--_cbaca81c-f322-4f31-8684-e7f171e67f3d_
>Content-Type: text/plain; charset="iso-2022-jp"
>Content-Transfer-Encoding: 7bit
>
>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:$B!!(B
>> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER;
>> >> $B!!(B
>> >> 
>> >> 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;
>> >> $B!!(B
>> >> 
>> >> - Jay
>> 
> 		 	   		  
>--_cbaca81c-f322-4f31-8684-e7f171e67f3d_
>Content-Type: text/html; charset="iso-2022-jp"
>Content-Transfer-Encoding: 7bit
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px;
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt;
>font-family:Verdana
>}
>--></style>
></head>
><body class='hmmessage'>But then unsafe, right?<br><br> - Jay<br><br>> From: hosking@cs.purdue.edu<br>> Date: Thu, 15 Apr 2010 22:06:14 -0400<br>> To: rodney_bates&
>#64;lcwb.coop<br>> CC: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] Modula-3/C interop in Date/Time?<br>> <br>> Indeed!  UNTRACED.<br>> <br>> <
>br>> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote:<br>> <br>> > Since these pointer variables are initialized by<br>> > C code and their referents are also provided by C
> code<br>> > as global variables, shouldn't the type be untraced?<br>> > <br>> > I suppose that, since they don't point into the traced<br>> > heap, the collect
>or implementation we have would quietly<br>> > ignore them as roots.  But that's relying on implementation-<br>> > dependent information.<br>> > <br>> > Also, if someon
>e created a field of type Date.TimeZone,<br>> &#62
> ; (or an array of them) in a traced-heap-allocated object,<br>> > which is a perfectly legitimate thing to do, what would<br>> > our collector do then?<br>> > <br>
>> > <br>> > <br>> > Jay K wrote:<br>> >> Is this legal/correct?<br>> >> <br>> >> <br>> >> Date.i3:<br>> >> TYPE TimeZone
> <: REFANY;<br>> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *)<br>> >> <br>> >> <br>> >>
> Date.m3:　<br>> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER;<br>> >> 　<br>> >> <br>> >> DatePosixC.c:<br>
>> >> static const int Local = 0;<br>> >> static const int UTC = 1;<br>> >> extern const int const * const Date__Local = &Local;<br>>
> >> extern const int const * const Dat
> e__UTC = &UTC;<br>> >> 　<br>> >> <br>> >> - Jay<br>> <br> 		 	   		  </body>
></html>
>--_cbaca81c-f322-4f31-8684-e7f171e67f3d_--