<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Recent quote, that I haven't further investigated, made me realize some of my ignorance.<BR>
<BR>
I know that "unsafe" includes:<BR>
taking address of local <BR>
explicit free <BR>
dealing with any untraced ref? Not sure.<BR>
<BR>
Questions are:<BR>
is unsafe well statically enforced?<BR>
and/or is safe well statically enforced?<BR>
<BR>
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?<BR>
<BR>
Or do I need to think about it myself?<BR>
<BR>
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.<BR>
<BR>
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"?<BR>
Maybe I should just reread that quote, and thing about it.<BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
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. <BR>
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...<BR>
<BR>
<BR>
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..<BR>
<BR>
<BR>
About right?<BR>
<BR>
<BR>
- Jay<BR><BR></body>
</html>