Re: Possible compiler bug with this simple program



On Aug 28, 1:03 am, Niklas Holsti <niklas.hol...@xxxxxxxxxxxxxxx>
wrote:

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.

Yes, good point. For an unconstrained array parameter like X, the
compiler doesn't need to know what X'Last is in order to access
elements of the array---but it does need to know X'First. (X'Last is
needed for range checking but not for actually accessing elements.)
If you're using strictly Ada, with no Convention parameters or
anything, then when mapform19 is called, the caller somehow has to
make X'First and X'Last available to the routine, and then when X(I)
is accessed, the generated code must compute I - X'First, multiply
that by the element size, and add the result to the address of X's
data. When mapform19 is called from a C routine, nothing will be
passed in for X'First, but mapform19 will still try to subtract
something from I, and what value it will subtract is quite random---
could be zero, could be some other garbage value.

I agree that the compiler should have rejected this. But it might
work to declare Real_Vector as a constrained array:

type Real_Vector is array (0 .. Integer'Last) of Long_Float;

Now the compiler will know that X'First is 0 and, hopefully, behave
correctly.

-- Adam

.



Relevant Pages

  • Re: Possible compiler bug with this simple program
    ... I suspect that one problem is using the C convention to pass a parameter that is of an unconstrained array type, ... B.3, the C convention passes only a single pointer to the first element of the array, so the 'Range attribute will not be available to the subprogram. ... The compiler should IMHO have rejected the use of x'range here, ... 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. ...
    (comp.lang.ada)
  • Re: incomplete array - why compiler error
    ... "pf" is a pointer to a function, ... (argument passing convention) ... to an array of an incomplete struct type, ... difference in the calling convention chosen by the compiler. ...
    (comp.std.c)
  • Re: Idea for ECMA/C# Standard - compile time hash for performance
    ... I agree with you the chance of a compiler change is slim, ... and then delegating to the standard hash for fields accessed less frequently. ... or the array lookup which would require the ... > 64-bit architecture) for each enum value that doesn't map to anything. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Anybody here endure C/Cpp? (.h to .inc conversion)
    ... Pascal or Stdcall convention... ... "PFNGLPOINTPARAMETERFEXTPROC" to be a type that's a pointer to a function ... DWORD, using a 32-bit compiler, with an address in it...adding the ... this is working on the premise that OpenGL does it like most others ...
    (alt.lang.asm)
  • Re: Q: Checking the size of a non-allocated array?
    ... an actual argument is already invalid ... First note that you don't have an unallocated array in the subroutine. ... it is comparable to disassociated or undefined pointers. ... Obviously the compiler has ...
    (comp.lang.fortran)