Re: Possible compiler bug with this simple program

[Jerry <lanceboyle@qwest.net>]

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 ============
>
> Now: Here are some integer declaration sizes for the OS X 32-bit
> version and the Debian 64-bit version. I could provide more but these
> should be more than sufficient if there is in fact a problem in this
> area.
>
> ===== OS X 32-bit sizes =====
> Integer bits is  32
> Long_Integer bits is  32
> Long_Long_Integer bits is  64
> Long_Float bits is  64
> In Interfaces.C, int bits is 32
> In Interfaces.C, long bits is 32
> In Interfaces.C, C_float bits is 32
> In Interfaces.C, double bits is 64
>
> ===== Debian 64-bit sizes =====
> Integer bits is  32
> Long_Integer bits is  64
> Long_Long_Integer bits is  64
> Long_Float bits is  64
> In Interfaces.C, int bits is 32
> In Interfaces.C, long bits is 64
> In Interfaces.C, C_float bits is 32
> In Interfaces.C, double bits is 64
>
> I'm inclined to think that there is a compiler problem that makes the
> 64-bit Debian version crash but am wondering if there could be a
> problem with word lengths that causes the problem.
>
> 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) is
that the compiler allows the second form at all. It looks like a
situation where a simple syntactically correct program bombs.

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.


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?