[M3devel] meaning of unsafe?

[Jay]

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.orgTo: jay.krell at cornell.eduDate: Fri, 2 Jan 2009 16:27:24 +0900CC: m3devel at elegosoft.comSubject: 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/f940db8e/attachment-0002.html>