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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,e5a3abec221df39 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!postnews.google.com!k36g2000pri.googlegroups.com!not-for-mail From: Jerry Newsgroups: comp.lang.ada Subject: Re: Possible compiler bug with this simple program Date: Wed, 3 Sep 2008 17:22:02 -0700 (PDT) Organization: http://groups.google.com Message-ID: <5ca524f3-0fde-4c3b-b1a0-fe2281180ef3@k36g2000pri.googlegroups.com> References: <1edc3682-855f-405b-8348-72b423377b1a@i20g2000prf.googlegroups.com> <48b65b3b$0$25384$4f793bc4@news.tdc.fi> <97b1150b-cb8f-4972-b594-2ae59af84147@x16g2000prn.googlegroups.com> <8c8e5e62-16e1-4442-a6e9-f4e63fbed7a8@a8g2000prf.googlegroups.com> <903354c9-7780-4843-a5a3-dd2c40903d40@p31g2000prf.googlegroups.com> <2da4989c-4c97-43e9-8102-ba99389fdea9@v16g2000prc.googlegroups.com> <0494a60a-a452-436b-86f9-844b398aab4f@b38g2000prf.googlegroups.com> NNTP-Posting-Host: 75.171.37.202 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1220487722 17582 127.0.0.1 (4 Sep 2008 00:22:02 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 4 Sep 2008 00:22:02 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: k36g2000pri.googlegroups.com; posting-host=75.171.37.202; posting-account=x5rpZwoAAABMN2XPwcebPWPkebpwQNJG User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US) AppleWebKit/525.18 (KHTML, like Gecko, Safari/525.20) OmniWeb/v622.1.0.104476,gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:7627 Date: 2008-09-03T17:22:02-07:00 List-Id: On Sep 3, 7:20=A0am, Adam Beneschan wrote: > > Several of us have pointed out that it's a bad idea to use an > unconstrained array type (i.e. Real_Vector) as a parameter to an > imported routine (or a routine with convention C), but the above code > still did it. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Adam In about a hundred cases in this same binding project, I have passed an unconstrained array (and its length) as a parameter to an Imported C subprogram without consequence--no warnings, no errors, no hangs--on several kinds of machines (32-bit and 64-bit). This seems to be allowed by ARM B.3.70: "An Ada parameter of an array type with component type T, of any mode, is passed as a t* argument to a C function, where t is the C type corresponding to the Ada type T." There is no restriction on unconstrained array types. The reason that I posted the modified code (mixed Ada and C) is that Randy's post indicated that it should work. In one instance (of the "hundred"), I "rename" one of these Imported C subprograms (it has two unconstrained arrays and their length as parameters). At the point of the "rename," GNAT generates two warnings, "foreign caller must pass bounds explicitly," and "type of argument "plfill.y" is unconstrained array." (plfill is the procedure name and y is one of the unconstrained arrays. A similar pair of warnings is generated for the other passed unconstrained array.) The purpose for renaming the procedure, which is originally declared as an Import with C conventions in another package (without warnings), is to allow the user to pass it as a callback to another Imported C subprogram. This works without problems. The difference between the two cases ([1] described above, herein, and [2] the code in mixed Ada and C that I posted earlier), is that in [1], both the called procedure and the callback procedure are written in C, and the in problematic code [2], the called subprogram is in C (plmap) but the callback (mapform19) is written in Ada, with C conventions. In a third scenario in the binding project [3], Ada successfully calls an Imported procedure written in C and passes a callback written in Ada with C conventions; this closely resembles the problematic code [2] except that in [3], the callback function is passed with 'Access and in [2] it is passed with 'Unrestricted_Access. Also, [3] doesn't pass an unconstrained array. (I don't see how to make [2] work with 'access without requiring the user to put the user-written callback into the binding package.) Jerry