Re: Possible compiler bug with this simple program

[Adam Beneschan <adam@irvine.com>]

On Sep 3, 5:22 pm, Jerry <lancebo...@qwest.net> wrote:
> On Sep 3, 7:20 am, Adam Beneschan <a...@irvine.com> 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