<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'> > In Modula-3, you can pass any procedure but only assign a top-level procedure.<BR> > This precludes dangling environments in yet another way, that is more liberal<BR> > than either Pascal or Modula-2,, but requires a runtime check on procedure<BR><BR>
I don't understand "can only assign a top-level procedure".<BR>
My understanding is that Modula-3 does allow the "unsafe" option -- take the address of a nested function, pass it off to some code, that stores it in a global, and call it later. But of course, "Modula-3 does allow the unsafe option" does not compute. I need to read up and experiment.<BR>
<BR>
Maybe there is a runtime check whenever I assign a function pointer to either a global or to a field in non-local record, that it isn't a closure?<BR>
That makes a fair amount of sense though hard to not make the check overly strict I think.<BR>
<BR>
Rodney my "problem" with your analysis is it mostly "pretends" that each language is its own independent environment.<BR>
In present reality at least, Modula-3 and C interoperate a lot. That is largely a good thing. It does place restrictions on Modula-3 implementations however.<BR>
Pointers to top-level Modula-3 functions can be passed to C and treated as pointers to C functions.<BR>
Pointers to C functions, including gcc nested functions, can be passed to Modula-3 code as pointers.<BR>
There are not separate types for pointers to C vs. Modula-3 functions.<BR>
Pointers to nested Modula-3 functions cannot be passed to C code and treated as C function pointers, though enabling this, with the programmer required to notice the situation and change the code slightly, is easy enough. The compiler might also be able to recognize it and possibly error, at least if "extern" is presumed to be C, though of course..insert one level of Modula-3 code between "taking the address" and "passing it to C", and it becomes more difficult..but maybe still quite easy.<BR>
<BR>
If the whole world was Modula-3, then you could just change the representation of all function pointers and how they are called.<BR>
<BR>
The strategy of optionally heap allocated frames -- when the address is taken of a nested function -- does kill multiple birds with one expensive stone.<BR>
- ability to pass function pointers to nested functions to C code, and store them anywhere <BR>
- ability to call nested functions after their caller has returned <BR>
- remove the check for the -1 marker which might possibly maybe just barely be unportable, and also slows down/bloats calls to function pointers (but at the cost of probably a more sever slow down) <BR>
- avoid the use of generated code on the stack <BR>
- still need to ensure the heap is executable but that's less of a problem, Windows for example at least exposes the ability to make the heap executable, besides the strategy of using VirtualAlloc.<BR>
<BR>
However it slows down existing code.<BR>
<BR>
Depending on which of these features is desirable, if in fact any at all, there are other options.<BR>
- leave it all alone (but continue talking about it :) ) <BR>
- put the code on the stack and call mprotect/VirtualProtect, as OpenBSD does for gcc nested functions <BR>
<BR>
- Jay<BR><BR><BR>
<HR id=stopSpelling>
<BR>
> Date: Sat, 31 May 2008 09:29:24 -0400<BR>> From: hendrik@topoi.pooq.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?<BR>> <BR>> On Fri, May 30, 2008 at 06:17:02PM -0500, Rodney M. Bates wrote:<BR>> > <BR>> > My one handy Algol68 book has the usual tutorial language book problem: it<BR>> > omits the cases you really need to look up. It only states that there will<BR>> > be problems if you use a dangling environment, but not whether the language<BR>> > specifies this should be detected by the language, or whether "all hell will<BR>> > break loose." I'm guessing it's the latter. The implementation technique<BR>> > Hendrik describes makes it a detected runtime error, but not unless/until<BR>> > you try to use the lost environment. This is more generous than Modula-3's <BR>> > rule.<BR>> <BR>> The actual Algol 68 definition does pronounce on this. The CDC <BR>> implementation was much more liberal than the language definition.<BR>> <BR>> Every reference/variable and every procedure has a scope. The scope of <BR>> a variable is the level on the run-time stack at which it is allocated. <BR>> Variables can be on the heap; this is global scope. The scope of a <BR>> procedure is the stack elvel at which its most local global identifier <BR>> is bound. Even if the identifier refers to an object on the heap, it is <BR>> the level at which it is bound that counts.<BR>> <BR>> There is a universal scope restriction: No object can refer to a more <BR>> local object. The constraint in the language definition is applied on <BR>> assignment.<BR>> <BR>> I know of no Algol 68 implementation that I can say for sure implements <BR>> this restriction with a run-time check. Of course it can be done, <BR>> either by tagging each pointer with an explicit mention of its stack <BR>> level (which takes space) or by comparing its value and comparing it to <BR>> various stack locations in a kind of search.<BR>> <BR>> The first release of the CDC algol 68 compiler just allocated all <BR>> variables on the heap, making the check unnecessary for safety. <BR>> Programmers almost never wrote code that passed procedures out-of-scope.<BR>> <BR>> Later releases performed static analysis to determine where it was safe <BR>> to allocate in the stack (almost all the time), and used the mechanism I <BR>> described earlier to check procedures when they were called if the <BR>> static check didn't suffice..<BR>> > <BR>> > And, of course, if your language is really dynamic, it could just say an<BR>> > environment is always accessible, requiring many or all activation records<BR>> > to be heap allocated.<BR>> <BR>> Which was a proposal made for the original Algol 68, but was turned <BR>> down. I think it should have been accepted. We would have had a <BR>> strongly-typed Scheme ahead of its time.<BR>> <BR>> -- hendrik<BR>> <BR><BR></body>
</html>