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,be7fa91648ac3f12 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!news-in.ntli.net!newsrout1-win.ntli.net!ntli.net!newspeer1-win.ntli.net!newsfe2-win.ntli.net.POSTED!53ab2750!not-for-mail From: "Dr. Adrian Wrigley" Subject: Re: Large arrays (again), problem case for GNAT User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.) Message-Id: Newsgroups: comp.lang.ada References: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Date: Thu, 14 Apr 2005 11:40:57 GMT NNTP-Posting-Host: 81.100.88.147 X-Complaints-To: http://www.ntlworld.com/netreport X-Trace: newsfe2-win.ntli.net 1113478857 81.100.88.147 (Thu, 14 Apr 2005 12:40:57 BST) NNTP-Posting-Date: Thu, 14 Apr 2005 12:40:57 BST Organization: ntl Cablemodem News Service Xref: g2news1.google.com comp.lang.ada:10455 Date: 2005-04-14T11:40:57+00:00 List-Id: On Wed, 13 Apr 2005 18:35:42 -0400, Robert A Duff wrote: > Why do you use malloc? Why didn't you write: > > Big := new Big_T; (I explain this in another post. There seems to be a bug in 'new's size calculation, causing it to fail) > ? I'm not sure it makes any difference in this case, > but in general, if you're going to play games with memory > allocation, you should use storage pools, rather than relying > on the hope that malloc returns something that the Ada compiler > likes. If you had an access to unconstrained array, the malloc > method would almost certainly fail, unless you wrap it in the proper > storage pool thing. I thought I read somewhere that 'import/export' of C pointer values into simple access values (without constraints/variants) is designed to work in the obvious way. If the access value is incompatible with a 'C' pointer, the compiler (GNAT) generates a warning. But it is obviously an area of potential hazard, relying on a compiler warning if code becomes broken. ... > I suspect your problem is an OS problem, and not a GNAT problem. Curiously, removing the word "constant" on the Size value allows the program to run fine! I think the crux of the problem is illustrated by the erroneous 'Address values. This problem occurs without needing valid memory allocated, and minises the risk of OS issues interfering. (failure of 'new' is a bit of a give-away too!) In doing these tests (triggered by a failure on a real application), I have characterised the problem, and now understand how to work around these 3.15p/x86 issues. I'm told that 3.14p and 3.15p have the problem, and 3.4, 5.01, and 4.0 prerelease work fine. (thanks Dan!) Thanks! -- Adrian