Re: Possible compiler bug with this simple program

Jerry wrote:
On Aug 28, 12:28 am, Jerry <lancebo...@xxxxxxxxx> wrote:

The following is a program which emulates the structure of a binding
to a bunch of C code (but there is no C code included here--it is all
Ada). This structure exhibits a behavior which I think might be a
compiler error but could be the result of incorrect declarations when
running on certain machines.

Specifically, the program compiles (with two warnings which are
expected and OK) and runs correctly on my machine, OS X 10.4.11
running GNAT 4.3.0 (32-bit PowerPC G4). However, on someone else's
box, a 64-bit Intel Duo running Debian lenny and GNAT 4.3.1-2, the
program compiles but bombs at runtime with

raised STORAGE_ERROR : stack overflow (or erroneous memory access)

reported.

However, on the Debian lenny machine, if the three lines with

--***

at the end of them are commented out (they relate to Pragma-C
conventions), the program compiles and runs correctly, printing out 10
lines of floats. (It also runs correctly on the OS X machine.)

Here is the program, stored in two files (damn the line wraps):

========== Begin program ==========

with
type_declaration,
Ada.Text_IO;
use
type_declaration,
Ada.Text_IO;

procedure x19a_temp is

procedure mapform19(n : Integer; x : in out Real_Vector); --***
pragma Convention(C, mapform19); --***

procedure mapform19(n : Integer; x : in out Real_Vector) is
begin
for i in 0 .. n - 1 loop
x(i) := Long_Float(i);
Put_Line(Long_Float'image(x(i)));
end loop;
end mapform19;

begin
plmap(mapform19'Unrestricted_Access);
end x19a_temp;

package type_declaration is

type Real_Vector is array (Integer range <>) of Long_Float;

type Map_Form_Function_Pointer_Type is access
procedure (Length_Of_x : Integer; x : in out Real_Vector);
pragma Convention(Convention => C,
Entity => Map_Form_Function_Pointer_Type); --***

procedure plmap(Map_Form_Function_Pointer :
Map_Form_Function_Pointer_Type);

end type_declaration;

========== End program ============
....
As a second problem, in the program above there is a loop line that
looks like this:

for i in 0 .. n - 1 loop

One would normally write this as

for i in x'range loop

but when this runs on the OS X box, it segfaults after printing about
187 lines of bogus floats. I don't know what happens on the Debian
box. However, if the -- *** lines are commented out, it runs OK on OS
X.

Comments?

Jerry



Thanks, everybody, for the comments.

As for the second problem ( in 0 .. n - 1 loop versus for i in x'range
loop), my main concern (since I have a workaround--the first form) ...

Even if the workaround using "in 0 .. n - 1" works on a given compiler and machine, according to Randy this depends on non-standard (ie. generally unportable) features of the compiler.

For example, Randy mentioned that Tucker's compiler would give the x-array "maximum bounds", which in this case seems to mean Integer'First .. Integer'Last, and so x(0) would lie somewhere far beyond the actual array in memory.

For "in 0 .. n-1" to work on Tucker's compiler, you should probably declare Real_Vector using Natural indices instead of Integer indices, to make the "maximum bounds" be 0 .. Natural'Last.

Also, I should have mentioned that the two warnings that are emitted
at compile time as a result of passing the unconstrained array via C
conventions are this:

x19a_temp.adb:10:38: warning: type of argument "mapform19.x" is
unconstrained array
x19a_temp.adb:10:38: warning: foreign caller must pass bounds
explicitly

I get this pair of warnings in other places where I do some callbacks
to C so I expected to see it here, as well, and I'm fine with that.

In C code there is no problem, as all arrays start at index 0. (Which, of course, leads to other problems, but they are on the design level :-)

Also, I apologize for not including the body part of type_declarations
which looks like this:

========== Begin body part ==========

package body type_declaration is

procedure plmap(Map_Form_Function_Pointer :
Map_Form_Function_Pointer_Type) is
xx : Real_Vector(0 .. 9);
begin
Map_Form_Function_Pointer(xx'length, xx);
end plmap;

end type_declaration;

========== End body part ==========

Does the declaration of xx here as a constrained array change anyone's
comments about array boundaries not being known later?

Not for me. Although the "xx" *object* is constrained, the *type* is still unconstrained. This is the point: Convention C means that the actual index range of "xx", although known at the point of call, is not passed to Map_Form_Function_Pointer.all.

If I understand Randy's explanation correctly, it does not even help to pass the index range explicitly (instead of passing just the length, as in your code), because the compiler invents some index range of its own for accessing the Convention C unconstrained-array parameter within the Ada body of the subprogram. For this code to work, you must just know what this invented index-range is, in your compiler.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
.

Relevant Pages

  • 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: 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)
  • Re: Windows array allocation problem
    ... array reference has to have a 64-bit index or array subscript triplet? ... to fit in one. ... That assumes, of course, that your compiler ... limits on just about anything. ...
    (comp.lang.fortran)
  • Re: Error handling library
    ... which lets the compiler catch out-of-range usage. ... and assuming that a higher int means "more dangerous error" ... with a comment warning that one is used as an index into the array ... languages while running (an array of languages, ...
    (comp.lang.c)
  • Bounds checked arrays
    ... As everybody knows, the C language lacks ... When the state of this toggle is ON, the compiler ... Important is to know that the array updates ... We have just to allow him/her to specify what to do ...
    (comp.lang.c)