[M3devel] meaning of unsafe?

[Darko]

The language def says:
In unsafe interfaces and modules the definition of "assignable" for  
types is extended: two reference types T and U are assignable if T <:  
U or U <: T. The only effect of this change is to allow a value of  
type ADDRESS to be assigned to a variable of type UNTRACED REF T. It  
is an unchecked runtime error if the value does not address a variable  
of type T.

In unsafe interfaces and modules the type constructor UNTRACED REF T  
is allowed for traced as well as untraced T, and the fields of  
untraced objects can be traced. If u is an untraced reference to a  
traced variable t, then the validity of the traced references in t is  
implementation-dependent, since the garbage collector probably will  
not trace them through u.


On 02/01/2009, at 5:16 PM, Jay wrote:

> The language offers optional safety, therefore safety has a meaning  
> "among" modules and interfaces.
> (heck, it might be interesting to have safe/unsafe functions, or  
> even blocks of code -- C# has safe/unsafe blocks of code, like  
> unsafe { do stuff })
>
> What is the meaning of an unsafe interface vs. a safe interface?
>
> I see one thing -- an unsafe module cannot import from a safe  
> interface.
> I tried that.
>
> I think you or Mika summed it up -- safe code can call into unsafe  
> code, but doing so must not violate "the usual safety" constraints".  
> Therefore, unsafe code must be "careful", i.e. bug-free (well, not  
> logically bug-free, but type-system bug-free -- no use of freed  
> pointers (nor dangling stack pointers, nor invalid addresses in  
> general), no double frees, no buffer overflows (or underflows), no  
> integer overflows, etc., and don't call into any such code either).
>
>  - Jay
>
>
>
> From: darko at darko.org
> To: jay.krell at cornell.edu
> Date: Fri, 2 Jan 2009 16:27:24 +0900
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] meaning of unsafe?
>
>
> Safety is a property of the language, not the procedures. A safe  
> module is one that doesn't use unsafe features and means the  
> language will guarantee that you will get no unchecked errors when  
> you run the code. And that guarantee is dependent on the compiler  
> and language definition being bug free.
>
> Outside that of that it is like asking if rocks feel guilty.  
> External modules are not written in M3 so they have no possibility  
> of safety in the M3 sense, unless they were written in a language  
> with an equivalent definition to M3. They might be reliable or bug  
> free, but that's not the same thing.
>
>
> On 02/01/2009, at 4:02 PM, Jay wrote:
>
> Recent quote, that I haven't further investigated, made me realize  
> some of my ignorance.
>
> I know that "unsafe" includes:
>   taking address of local
>   explicit free
>     dealing with any untraced ref? Not sure.
>
> Questions are:
>   is unsafe well statically enforced?
>   and/or is safe well statically enforced?
>
> That is, should I remove unsafe "everywhere", as long as it compiles  
> ok, it must be safe, and better, so leave it that way? And if it  
> fails, put it back?
>
> Or do I need to think about it myself?
>
> I think for modules it might be brainless as stated -- put it in  
> only where the compiler makes, and nowhere extra, since extra is a  
> loss not a bonus.
>
> But for interfaces.. I think, again, ideal to remove it where you  
> can, but that the compiler can't enforce it? At least where there is  
> "external"?
> Maybe I should just reread that quote, and thing about it.
>
> Safe can code call unsafe code, but should not be able to do so with  
> parameters that, indirectly, make the safe code unsafe. For example,  
> I cannot safe call "free" in unsafe code on behalf of safe code,  
> unless I am darn sure the data isn't referenced -- unless I am the  
> garbage collector. Any pointer give to unsafe code by safe code must  
> not be stored "long term" -- ie: in the heap or globals, because it  
> could be a stack pointer. Unless, well, duh..ok, any VAR parameter  
> or UNTRACED REF passed to unsafe code, what I just said, but traced  
> refs can be held onto -- they are by definition not stack pointers.
>
> I guess, you know..programming C code that interacts with Modula-3  
> code..you realize the incompleteness of the C type system. Modula-3  
> has, let's say, var, traced ref, and untraced ref. C just has  
> pointers. The compiler doesn't know any better, the programmer has to.
>
> If you imagine a Modula-3 to C header compiler..which I would  
> like..you know, it outputs C headers that map FROM Modula-3  
> interfaces (instead of the usual hand translations in either  
> direction), it would likely lose a lot of information and only be  
> for special purpose use, unless, unlikely, not likely valuable, this  
> problem was solved.
> Which..oh, this is interesting..I can see, to solve this, you'd need  
> an "API" for storing pointers perhaps. Something perhaps to make  
> sure the pointer is allowed to be stored like such. Not sure. But I  
> suspect this "API" is related to the "checks" that the Modula-3  
> compiler generates...I really need to understand those...
>
>
> Generally this is easy, because generally things are "synchronous"  
> -- generally the C code doesn't hold on to its parameters beyond the  
> lifetime of itself -- doesn't store it in the heap or globally for  
> other threads to use, and generally the Modula-3 code isn't busy  
> freeing the parameters on another thread, in fact VAR parameters  
> cannot be freed, they are on the stack, and traced refs can only be  
> freed..if the garbage collector can't find any references to  
> them..and then untraced refs require "discipline" both in the  
> Modula-3 code and the C code, but again generally, saved by  
> "synchronicity" -- C code doesn't hold on to them, Modula-3 code  
> doesn't free them on another thread. Those scenarios are certainly  
> possible, just not all that common, and as soon as you "escape" to  
> safe Modula-3 code, not a possibility..no untraced refs..
>
>
> About right?
>
>
>  - Jay
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090102/90d7d909/attachment-0002.html>