<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@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 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;<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>