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: g2news2.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!news-out1.kabelfoon.nl!newsfeed.kabelfoon.nl!bandi.nntp.kabelfoon.nl!news.banetele.no!uio.no!fi.sn.net!newsfeed1.fi.sn.net!news.song.fi!not-for-mail Date: Fri, 29 Aug 2008 10:41:17 +0300 From: Niklas Holsti 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: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <48b7a778$0$23608$4f793bc4@news.tdc.fi> Organization: TDC Internet Services NNTP-Posting-Host: laku61.adsl.netsonic.fi X-Trace: 1219995513 news.tdc.fi 23608 81.17.205.61:32807 X-Complaints-To: abuse@tdcnet.fi Xref: g2news2.google.com comp.lang.ada:7545 Date: 2008-08-29T10:41:17+03:00 List-Id: Jerry wrote: > On Aug 28, 12:28 am, 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. >> >>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 . @ .