Re: Possible compiler bug with this simple program

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 ============

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?
.

Relevant Pages

  • Re: Definition of expression and statement.
    ... correct C compiler at all -- it must implement those things the C ... which is the same thing the stupid compiler produces for the ... Still, for most purposes, one mostly wants to turn optimization ...
    (comp.lang.c)
  • Re: pydoc enforcement.
    ... following features/extension for the python compile stage and would be ...   1) pydoc's are written for every function/method. ... class Foo(object): ... What I think could be interesting is that the compiler forces some ...
    (comp.lang.python)
  • Re: RAD vs. performance
    ... I wasn't arguing that it's not possible in OCaml, ... You wouldn't use the full program compiler when you're developing. ...     done; ... your abstraction, i.e. the worst-case scenario for dynamic typing. ...
    (comp.lang.misc)
  • Re: Otto Normalverbraucher
    ... Es gibt sicher Leute, denen die ...   ... Linux und damit SuSE ist ... einigen Versuchen mit Debian und diversen Derivaten (Sidux, Knoppix, ...
    (de.comp.os.unix.linux.misc)
  • Re: spinoza programming language and big numbers
    ... ##  Compiling the compiler ... ...   var integer: twee is 0; ... Which bigInteger bit functions would be needed? ... Seed7 newbie. ...
    (comp.programming)