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!news2.google.com!newsread.com!news-xfer.newsread.com!news-feed01.roc.ny.frontiernet.net!nntp.frontiernet.net!newscon06.news.prodigy.com!prodigy.net!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Large arrays (again), problem case for GNAT Date: 14 Apr 2005 11:03:17 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1113490997 26978 192.74.137.71 (14 Apr 2005 15:03:17 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Thu, 14 Apr 2005 15:03:17 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:10462 Date: 2005-04-14T11:03:17-04:00 List-Id: "Dr. Adrian Wrigley" writes: > Hi! > > Thank you very much for the feedback on this, particularly > those reporting success on particular configurations. > > I should also comment: > > I used 'malloc' rather then 'new' for two reasons: > > 1) Using 'new' fails, giving "raised STORAGE_ERROR : object too large" > (in spite of having enough store to malloc and use) 'malloc' should work for the case you showed, where the array is constrained, and there are no default initializations, etc. In more complicated cases, you would need to hide 'malloc' behind a storage pool in order to make things work properly. > 2) My original program used 'mmap', but this is much more verbose > to set up. On Linux, large 'malloc' uses mmap anyway. > > I calculate the size to allocate manually because attempting > to use the 'Size attribute fails (even when converted to a > suitably large type). > > In fact the 'Size attribute fails on objects over 2147483647 bits :( > Sometimes this failure is silent (not trapped even with -gnato), > sometimes it gets a constaint error at compile time. Yeah, it was a language design mistake to measure everything in bits. In 1983, it might have been unthinkable that a single object would be as big as 1/8 the address space on a 32-bit machine. But 16-bit machines with 16 bits worth of real memory were common in those days, and the same issue arises there. But surely silent overflow is a compiler bug! Actually, now that I think about it, it seems like non-silent overflow is a compiler bug too. The value of 'Size is universal_integer. And there's a rule somewhere (which I'm too lazy to look up) that says non-static values of type universal_integer must be calculated using the largest integer type allowed. Since GNAT supports 64-bit integers, it ought to be using that for 'Size when necessary. Of course, this is not portable, since compiles are not required to support 64-bit integers. - Bob