[M3devel] function pointers and comparison to nil? mis-typed function pointers?

[Rodney M. Bates]

I still want to obsess on variables of type procedure/pointer-to-function,
because some of the discussion appears to me to maybe forgetting that each
language has a definition, and language implementors should adhere to it.
These are not the bad old days of the 1960s, when the only authority on the
semantics of a language was "whatever our particular compiler does".

The various languages have different rules for dealing with the problem of
dangling environment pointers in procedure variables, and these affect the
implementation choices.

In Pascal, procedures can be passed as parameters but never assigned,
regardless of whether nested or not.  It is a consequence of normal
lifetime rules that dangling environments can't happen.  The most obvious
implementation is to always use a traditional, two-word closure, nested or
not, so no marker is needed   This has an environment pointer and a code
pointer.

In Modula-2, procedures can be both passed and assigned, but only global
procedure values are allowed.  This can be checked statically and prevents
dangling environment pointers in a different way.  No environment pointer
is needed, so one-word pointers to code can be used as the implementation.

In Modula-3, you can pass any procedure but only assign a top-level procedure.
This precludes dangling environments in yet another way, that is more liberal
than either Pascal or Modula-2,, but requires a runtime check on procedure
assignments.  Modula-3 could be implemented using always two-word closures
with no marker, or the way it is.

In C, as extended by gcc, dangling environment pointers can happen and the
language makes no attempt to prevent them.  In the words of the gcc manual,
if you use one, "all hell will break loose".  Trampolines implement this
fine, while keeping pointers to global functions having the expected,
one-word representation.

My one handy Algol68 book has the usual tutorial language book problem: it
omits the cases you really need to look up.  It only states that there will
be problems if you use a dangling environment, but not whether the language
specifies this should be detected by the language, or whether "all hell will
break loose."  I'm guessing it's the latter. The implementation technique
Hendrik describes makes it a detected runtime error, but not unless/until
you try to use the lost environment.  This is more generous than Modula-3's rule.

And, of course, if your language is really dynamic, it could just say an
environment is always accessible, requiring many or all activation records
to be heap allocated.

Though it's obviously desirable,  Supporting all this for mixtures of
languages is, IMO, highly unrealistic without a lot of cooperation among
the developers of all the compilers of all the languages involved.  And this
involves both defining semantics and coming up with compatible implementations.
The horse is already long gone from the barn on other language definitions
and their compilers.

The system we now have is actually a quite good after-the-fact compromise.
It correctly implements Modula-3, and allows free intermixing of C and Modula-3
procedure/pointer-to-function values, as long as the values are not nested.
It also doesn't require an executable stack.  Not bad, considering we have
no influence on any other language definers or compiler writers.

Jay wrote:
>  
> Even though nested functions are a gcc extension to the C language, 
> email threads out there discuss Ada, Pascal, and even ! Modula-3 as 
> having nested functions, and that therefore deprecating the C language 
> feature doesn't "solve" the "problem".
>  
> I remain uncertain what, if anything, to do here.
>  - keep the -1 hack, do nothing
>     generalize it slightly to let targets pick "better" markers
>  - use gcc's supported for nested functions
>    (plus the integrated backend, not difficult)
>  
> Clearly this is a dilemna to more than just me. :)
>  
>  - Jay
>
-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu