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