<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
The functions are meant to be unsafe either way.<br>ThreadF.i3 clearly had a safety hole before, but not due to the functions "in question".<br><br>Good point about passing in ADDRESSes..but I'm not entirely sure I understand/agree.<br>Can safe code ("directly") generate any ADDRESSes at all? Or only get them from<br>unsafe code in the first place?<br>ADDRESS only comes from ADR, right? And ADR isn't allowed in safe? I'll check.<br><br>IF safe code CAN generate ADDRESSes, then this was a hole:<br>PROCEDURE SetCurrentHandlers(h: ADDRESS);<br><br>and perhaps these:<br>PROCEDURE SuspendOthers ();<br>(* Suspend all threads except the caller's *)<br><br>PROCEDURE ResumeOthers ();<br><br>Though probably not the second, since safe code can trivially hang/deadlock on its own.<br><br>The public safe ThreadF.i3 now just:<br><br>(*-------------------------------------------------- showthreads support ---*)<br><br>TYPE<br> State = {<br> alive (* can run *),<br> waiting (* waiting for a condition via Wait *),<br> locking (* waiting for a mutex to be unlocked *),<br> pausing (* waiting until some time is arrived *),<br> blocking (* waiting for some IO *),<br> dying (* done, but not yet joined *),<br> dead (* done and joined *)<br> };<br><br>(*-------------------------------------------------------------- identity ---*)<br>
<br>TYPE<br> Id = INTEGER;<br><br>PROCEDURE MyId(): Id RAISES {};<br>(* return Id of caller *)<br><br><br>Everything else I moved to the non-public ThreadInternal.i3.<br><br><br>> But in Modula-3 whether an interface is unsafe or not *is* a boolean.<br><br>Understood, but I still think even in unsafe code, LOOPHOLE should be minimized.<br>C and C++ programmers are often taught to minimize casts, esp. reinterpret_cast.<br>I think that guidance carries over to Modula's LOOPHOLE, even if you are already unsafe<br>for other reasons.<br><br> - Jay<br><br><br>> To: jay.krell@cornell.edu<br>> CC: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] RC merge <br>> Date: Sun, 13 Sep 2009 02:44:50 -0700<br>> From: mika@async.async.caltech.edu<br>> <br>> Jay K writes:<br>> ...<br>> ><br>> >Imagine you are a somewhat prolific fairly happy C or C++ programmer. The w=<br>> >hole world is unsafe=2C but recieves a fair amount of static checking and i=<br>> >s therefore largely correct and perhaps doesn't even suffer much from the l=<br>> >ack of safety.<br>> ><br>> >=20<br>> ><br>> > void* GetFoo(void)=3B=20<br>> ><br>> > void* GetBar(void)=3B=20<br>> ><br>> >=20<br>> ><br>> >or<br>> ><br>> >=20<br>> ><br>> > Foo_t* GetFoo(void)=3B=20<br>> ><br>> > Bar_t* GetBar(void)=3B=20<br>> ><br>> >=20<br>> ><br>> >?<br>> ><br>> >=20<br>> ><br>> >Definitely the second.<br>> ><br>> >=20<br>> ><br>> >Perhaps perhaps perhaps perhaps a function should be able to be declared to=<br>> > return an UNTRACED REF Foo.Something=2C without actually importing Foo or =<br>> >defining Something?<br>> ><br>> >=20<br>> ><br>> >Clearly the safety of an /interface/ is more subtle than a boolean.<br>> ><br>> >Some functions may be safe and others unsafe.<br>> ><br>> >Even some uses of functions.<br>> ><br>> >Imagine for example:<br>> ><br>> >=20<br>> ><br>> >PROCEDURE GetFoo(): UNTRACED REF Foo.Something=3B<br>> ><br>> >=20<br>> ><br>> >Perhas a safe function could call this function=2C as long as it only compa=<br>> >res the return value to NIL?<br>> ><br>> >Actually storing it in a variable would require IMPORT Foo=2C and if FOO is=<br>> > declared UNSAFE=2C then that would<br>> ><br>> >pollute the caller. Or maybe merely declaring a variable of UNTRACED is eno=<br>> >ugh to wreck safety?<br>> <br>> But in Modula-3 whether an interface is unsafe or not *is* a boolean.<br>> It's very clearly defined what it means in the Green Book.<br>> <br>> If you don't declare your GetFoo as UNSAFE you can write<br>> <br>> VAR x := GetFoo; BEGIN (* manipulate fields of x *) END<br>> <br>> in safe code.<br>> <br>> Declaring GetFoo to return ADDRESS won't let you do that. Hence,<br>> it's safer, if there's a safety problem with manipulating the fields.<br>> <br>> An interface can hardly assume that it is the only one injecting objects<br>> of type ADDRESS into the "safe world" so if you're allowing the safe world<br>> to pass these objects back in your interface you have to sanity-check<br>> them anyhow. You do not, however, need to worry about the fields having<br>> been changed by the safe code.<br>> <br>> If you need some more subtle properties than that you probably ought<br>> to be writing UNSAFE code in the first place. Or is there some trickery<br>> you can do along the lines of what we came up with for small integers<br>> in pointers?<br>> <br>> Mika<br></body>
</html>