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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: 
 border2.nntp.dca1.giganews.com!nntp.giganews.com!news.snarked.org!aioe.org!.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: What exactly is the licensing situation with GNAT?
Date: Sat, 15 Nov 2014 10:18:23 +0100
Organization: cbb software GmbH
Message-ID: <dilqwcbqc502$.l6p0xx7myoiu.dlg@40tude.net>
References: <DA%7w.753721$Y4.288171@fx24.iad>
 <22a3816a-4e89-48f0-a126-dce581781beb@googlegroups.com>
 <mqw8w.739469$w82.82975@fx21.iad>
 <cd91630f-d78d-4eab-830c-f71005e93fc0@googlegroups.com>
 <084b1934-9641-425e-85ec-293e0334413e@googlegroups.com>
 <86bf69c8-eb08-4696-b6c9-3784f5c42213@googlegroups.com>
 <Jwy8w.500685$Ub6.487517@fx20.iad>
 <d4b8f45d-e327-4d78-a0d6-838aba063e4d@googlegroups.com>
 <lyoascltws.fsf@pushface.org> <YYE8w.620042$Lj7.284655@fx22.iad>
 <87389olqie.fsf@ixod.org> <zTF8w.509165$No4.167804@fx19.iad>
 <fca06fd0-6970-46a5-95b9-6b6317a37f7c@googlegroups.com>
 <aSG8w.567817$Q61.266688@fx13.iad> <m40odq$tdv$1@loke.gir.dk>
 <19fa65d4-72c9-44ab-b44b-4ea0929c18f2@googlegroups.com>
 <m412nj$av5$1@loke.gir.dk> <m41pge$si1$1@dont-email.me>
 <m4395r$bo5$1@loke.gir.dk> <fo7cw4s3dd6g$.1jh55iopdn64m$.dlg@40tude.net>
 <m45vef$3so$1@loke.gir.dk>
Reply-To: mailbox@dmitry-kazakov.de
NNTP-Posting-Host: wfRpp7ltpEWhI2na6kgpfA.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: 40tude_Dialog/2.0.15.1
X-Notice: Filtered by postfilter v. 0.8.2
Xref: number.nntp.giganews.com comp.lang.ada:190660
Date: 2014-11-15T10:18:23+01:00
List-Id: <comp.lang.ada>

On Fri, 14 Nov 2014 16:24:14 -0600, Randy Brukardt wrote:

> OTOH, I don't see why this would be any different than access types 
> vis-a-vis interfacing with C and the like. The type would have a 
> representation (likely one similar to access-to-subprogram), and that's the 
> problem for 'Unrestricted_Access - it needs a different representation to 
> support 'Unrestricted_Access from 'Access. And the representation needed for 
> 'Unrestricted_Access is incompatible with C (other than on GCC, which is 
> unusual). If you simply allowed any subprogram to match a subprogram type, 
> you couldn't allow interface to C. Or you'd have to have an accessibility 
> check on the use only for interface to C. Or some other messy rule - would 
> not gain anything.

Except that whatever checks needed they will not include pointer checks. If
a nested subprogram cannot be passed to C, then it cannot. But the reason
shall not be accessibility pointer check. The only reason allowed is
"cannot implement pragma Convention".

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de