From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,bbbeae4ed07e9626
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Address to function pointer conversion
Date: 1997/06/14
Message-ID: <dewar.866334272@merv>#1/1
X-Deja-AN: 248484192
References: <5nrq5h$13cm@info4.rus.uni-stuttgart.de>
 <5nrv4p$340m$1@prime.imagin.net>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-06-14T00:00:00+00:00
List-Id: <comp.lang.ada>


Sam says

<<Depends on how you define "correctly."
 
There is no such conversion defined within the language, because the
language would need some way to verify that this address is the
correct place to enter a routine with the given profile.>>


It is worse than that. There is no guarantee at all that an access to
function value looks anything like an address. 

Indeed, on the list of future enhancements for GNAT is to replace the
current inefficient use of trampolines for pointers to nested functions
by using "fat" pointers that will have two items

1) the address of the code
2) the static link

And this is indeed probably the most sensible data structure to use for
a pointer to a function (it is what is often used in Pascal and PL/1
compilers for example).

This means that even if UC is working today in GNAT on some implementation,
it may suddenly stop working in the future.

What would be helpful is to know why you would want to do such a strange
thing ...
dp