<html><head><base href="x-msg://608/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Why unsafe? Depends what you do with it.<div>
<br><div><div>On 16 Apr 2010, at 00:24, Jay K wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class="hmmessage" style="font-size: 10pt; font-family: Verdana; ">But then unsafe, right?<br><br>- Jay<br><br>> From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> Date: Thu, 15 Apr 2010 22:06:14 -0400<br>> To:<span class="Apple-converted-space"> </span><a href="mailto:rodney_bates@lcwb.coop">rodney_bates@lcwb.coop</a><br>> CC:<span class="Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> Subject: Re: [M3devel] Modula-3/C interop in Date/Time?<br>><span class="Apple-converted-space"> </span><br>> Indeed! UNTRACED.<br>><span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote:<br>><span class="Apple-converted-space"> </span><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>> ><span class="Apple-converted-space"> </span><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>> ><span class="Apple-converted-space"> </span><br>> > Also, if someone created a field of type Date.TimeZone,<br>> ! 2; (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>> ><span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><br>> > Jay K wrote:<br>> >> Is this legal/correct?<br>> >><span class="Apple-converted-space"> </span><br>> >><span class="Apple-converted-space"> </span><br>> >> Date.i3:<br>> >> TYPE TimeZone <: REFANY;<br>> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *)<br>> >><span class="Apple-converted-space"> </span><br>> >><span class="Apple-converted-space"> </span><br>> >> Date.m3: <br>> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER;<br>> >> <br>> >><span class="Apple-converted-space"> </span><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 D! ate__UTC = &UTC;<br>> >> <br>> >><span class="Apple-converted-space"> </span><br>> >> - Jay<br>><span class="Apple-converted-space"> </span><br></div></span></blockquote></div><br></div></body></html>