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!newspeer1.nac.net!newsfeed1.swip.net!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: What exactly is the licensing situation with GNAT? Date: Tue, 18 Nov 2014 10:04:34 +0100 Organization: cbb software GmbH Message-ID: <1mu315trs1kqt$.lz9invi2yjmh.dlg@40tude.net> References: <084b1934-9641-425e-85ec-293e0334413e@googlegroups.com> <86bf69c8-eb08-4696-b6c9-3784f5c42213@googlegroups.com> <87389olqie.fsf@ixod.org> <19fa65d4-72c9-44ab-b44b-4ea0929c18f2@googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: nyHeW7QjJmC1odUjK4LkDA.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:190817 Date: 2014-11-18T10:04:34+01:00 List-Id: On Mon, 17 Nov 2014 18:37:28 -0600, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:dilqwcbqc502$.l6p0xx7myoiu.dlg@40tude.net... >> 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". > > Huh? The problem is that (some) nested subprograms cannot be passed to C. > And allowing them to be passed in Ada is unconsonably expensive (at the very > least, you'll need a mechanism to say that you don't want to pay for that > overhead). What does pragma convention have to do with it? If you want to reject a subprogram being passed to C then that should be because of pragma Convention. Passing a subprogram to Ada should be always possible. If you wanted, for whatever reason, disable certain cases that would be still possible to do using type or subtype errors. My argument is that the cases where you might want to prohibit are not exactly the cases where accessibility checks fail, they are much fewer or non-existent. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de