[M3devel] meaning of unsafe?

[Darko]

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/58b87d4c/attachment-0002.html>