Re: Possible compiler bug with this simple program

[Jerry <lanceboyle@qwest.net>]

On Aug 28, 2:01 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "Niklas Holsti" <niklas.hol...@tidorum.invalid> wrote in message
>
> news:48b65b3b$0$25384$4f793bc4@news.tdc.fi...
> ...
>
> > In fact, when an Ada subprogram has an unconstrained array parameter with
> > Convention C, it seems to me that the subprogram's body cannot make any
> > use of individual elements of the array, because it doesn't know the index
> > range, so the compiler should reject any indexing of such an array
> > parameter, as well as any attempt to pass it on as a Convention Ada
> > parameter.
>
> This is the subject of AI05-0002-1. (It was carried over from the Ada 95.)
> [Now, I have to go look this one up because I don't remember anything about
> what we decided...] Ah, yes:
>
> "We do not require support for C convention interfacing pragmas for
> unconstrained
> array objects, unconstrained array function results, and most unconstrained
> array parameters."
>
> In particular, "An implementation need not support ... an Export or
> Convention pragma applied to a subprogram which has a parameter of an
> unconstrained array subtype;". The wording goes on to include unconstrained
> array objects and function results as well.
>
> Note that an implementation *can* support this if it wants; some
> implementations do implement this with various meanings (Tucker reported
> that their compiler gives the array maximum bounds) and it was thought to be
> bad to break user programs that depend on such behaviors. But if it does
> support it, it ought to do something sensible (raising random exceptions
> doesn't count). (Also note that it is required to support pragma Import in
> this case, as C doesn't care about the bounds and they can just be dropped.)
>
> > Conclusion: Your program tries to do something that cannot possibly work,
> > but the compiler should have told you so.
>
> Well, not necessarily (see Tucker's implementation, for instance). But
> either it should do something defined *or* reject it at compile-time.
> (Janus/Ada would have rejected the Convention pragma.) In any case, it is
> not required to support this in any useful way, and, as it is not portable,
> it should be avoided.
>
>                                        Randy.

Thanks, Randy. This is useful.

Superficially, in my situation, it appears that GNAT 4.3.0 on OS X PPC
supports it and GNAT 4.3.1-2 on Debian lenny on Intel duo does not
support it. I suppose there could be an element of dumb luck of GNAT
is not supposed to support it and it just happens to work on OS X. On
the other hand, if GNAT is supposed to support it then the Debian/
Intel version is broken.

The fact that warnings are issued (see my other post today where I
actually list the two warnings) indicates that passing unconstrained
arrays is supported but the caller had better not screw things up by
trying to access outside bounds (which my example handles correctly).
If that is the case, it looks like the Debian/Intel box is broken.

And yes, portability isn't good, according to your report.

FWIW, in the _real_ application that I am working on, plmap is written
in C (and accessed from my binding by an Import).

Do AdaCore people have any comments on this?

Jerry