Re: Possible compiler bug with this simple program

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

Jerry wrote:
> On Aug 28, 12:28 am, Jerry <lancebo...@qwest.net> 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
       .      @       .