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-7-bit Path: g2news1.google.com!postnews.google.com!s20g2000prd.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Possible compiler bug with this simple program Date: Wed, 3 Sep 2008 18:18:56 -0700 (PDT) Organization: http://groups.google.com Message-ID: <90006a35-e933-40f1-9a76-5698b0ce75d1@s20g2000prd.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> <5ca524f3-0fde-4c3b-b1a0-fe2281180ef3@k36g2000pri.googlegroups.com> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1220491136 29189 127.0.0.1 (4 Sep 2008 01:18:56 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 4 Sep 2008 01:18:56 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: s20g2000prd.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.7.12-1.3.1,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:1901 Date: 2008-09-03T18:18:56-07:00 List-Id: On Sep 3, 5:22 pm, Jerry wrote: > On Sep 3, 7:20 am, 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. > > > -- 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. This talks about passing an unconstrained array parameter *from* an Ada routine *to* a C function. You're doing more than that---you're having the C function pass the unconstrained array parameter back *to* an Ada routine, which the manual says nothing about. > The reason that I posted the modified code (mixed Ada and C) is that > Randy's post indicated that it should work. I think there must be a misunderstanding. In one of his posts he seemed to imply that it should work to pass an unconstrained array parameter to a C routine on all Ada compilers, but he then referred to the program as "unportable garbage". In another post he said that either the Ada compiler should document what should happen when an unconstrained array parameter is passed from C to Ada and implement it that way consistently (e.g. it should just decree that the lower bound is 0 and document it that way---but that's just one possible way of handling it), or reject the program. GNAT apparently doesn't do either so it's defective. The bug in GNAT, I believe, is that it compiles your Ada program in the first place---just my opinion. > 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. Yup, this is not surprising at all to me. And if you go back and reread my earlier post, I believe I explained pretty thoroughly why this is happening, and also gave you a solution. Don't use an unconstrained array type in your callback routine. Period. You can use unconstrained arrays when calling C routines from Ada; but if you're going to call Ada routines from C, don't. -- Adam