From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,e5a3abec221df39
X-Google-Attributes: gid103376,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news4.google.com!feeder.news-service.com!news-out2.kabelfoon.nl!newsfeed.kabelfoon.nl!xindi.nntp.kabelfoon.nl!news.banetele.no!uio.no!fi.sn.net!newsfeed1.fi.sn.net!news.song.fi!not-for-mail
Date: Thu, 28 Aug 2008 11:03:43 +0300
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.7.8) Gecko/20060628 Debian/1.7.8-1sarge7.1
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Possible compiler bug with this simple program
References: 
 <1edc3682-855f-405b-8348-72b423377b1a@i20g2000prf.googlegroups.com>
In-Reply-To: 
 <1edc3682-855f-405b-8348-72b423377b1a@i20g2000prf.googlegroups.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <48b65b3b$0$25384$4f793bc4@news.tdc.fi>
Organization: TDC Internet Services
NNTP-Posting-Host: laku61.adsl.netsonic.fi
X-Trace: 1219910459 news.tdc.fi 25384 81.17.205.61:32851
X-Complaints-To: abuse@tdcnet.fi
Xref: g2news1.google.com comp.lang.ada:1807
Date: 2008-08-28T11:03:43+03:00
List-Id: <comp.lang.ada>

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

I suspect that one problem is using the C convention to pass a 
parameter that is of an unconstrained array type, see below.

> 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):
> 
...
> 
> 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
...
> 
> 
> package type_declaration is
> 
>     type Real_Vector is array (Integer range <>) of Long_Float;

So Real_Vector is an unconstrained array type. According to RM 
B.3(70), 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.

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

My guess: the compiler implements convention C for the x parameter, 
which means x'range is not available, but the code for the second 
quoted for-loop tries to access x'range anyway -- boom! The 
compiler should IMHO have rejected the use of x'range here, with an 
error message.

Using the first form of the quoted loop may trigger the same 
problem in the code that checks that x(i) has a valid index, i.

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.

Conclusion: Your program tries to do something that cannot possibly 
work, but the compiler should have told you so.

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