<html><head><base href="x-msg://611/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>What is the use-case here?</div><div><br></div><div>Merely having UNTRACED references doesn't make your code unsafe. Using ADR does.</div><div><br></div><div>But why not have an interface with C that makes use of the fact that VAR parameters are passed as pointers to C.</div><div><br></div><div>e.g., C function</div><div><br></div><div>f(int *ref p)</div><div><br></div><div>can be declared as</div><div><br></div><div><*EXTERNAL*> f(VAR i: INTEGER)</div><div><br></div><div>and this is still safe.</div><br>
<br><div><div>On 16 Apr 2010, at 04:18, 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; ">Isn't making them unsafe? ADR? I'll try..<br><br>- Jay<br><br>> To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> Date: Fri, 16 Apr 2010 00:00:34 -0700<br>> From:<span class="Apple-converted-space"> </span><a href="mailto:mika@async.async.caltech.edu">mika@async.async.caltech.edu</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>> I don't think there's anything unsafe about UNTRACED.<br>><span class="Apple-converted-space"> </span><br>> It's DISPOSE that's unsafe...<br>><span class="Apple-converted-space"> </span><br>> Mika<br>><span class="Apple-converted-space"> </span><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:<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: m3dev<span class="Apple-converted-space"> </span><a href="mailto:el@elegosoft.com">el@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>> >> > (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& #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>> >> >><span class="Apple-converted-space"> </span><br>> >> >> - Jay<br>> >><span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><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 2;<br>> ><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&<br>> >#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>> >br>> On 15 Apr 2010, at 18:44, Rodney M. Bates wrote:<br>> <br>> > Since these pointer variables are initialized by<br>> & #38;#62; C code and their referents are also provided by C<br>> > 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<br>> >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<br>> >e created a field of type Date.TimeZone,<br>> ><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>> > <br>> > Jay K wrote:<br>> >> Is this legal/correct?<br>> >> <br>> >> <br>> >> Date.i3:<br>> >> TYPE TimeZone<br>> > <: REFANY;<br>> >> VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *)<br>> >> <br>> >&# 38;#62; <br>> >><br>> > Date.m3:　<br>> >> REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER;<br>> >> 　<br>> >> <br>> >> DatePosixC.c:<br><br>> >> >> static const int Local = 0;<br>> >> static const int UTC = 1;<br>> >> extern const int const * const Date__Local = &Local;<br>><br>> > >> extern const int con st * const Dat<br>> > e__UTC = &UTC;<br>> >> 　<br>> >> <br>> >> - Jay<br>> <br> </body><br>> ></html><br>> >--_cbaca81c-f322-4f31-8684-e7f171e67f3d_--<br></div></span></blockquote></div><br></body></html>