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,c022fc5445abd13d X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!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: Discriminated types with default discriminants Date: 02 Dec 2005 13:22:22 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <1131062882.814405.147150@g44g2000cwa.googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1133547742 20601 192.74.137.71 (2 Dec 2005 18:22:22 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Fri, 2 Dec 2005 18:22:22 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:6721 Date: 2005-12-02T13:22:22-05:00 List-Id: "Randy Brukardt" writes: > "Adam Beneschan" wrote in message > news:1131062882.814405.147150@g44g2000cwa.googlegroups.com... > > Robert A Duff wrote: > > > > > > A few compilers will add a level of indirection, and store the > > > > variable-sized stuff elsewhere, reallocating storage when the amount > > > > available is not big enough. > > > > > > It is quite difficult to get the indirect approach to work right. > > > Think about renaming a subcomponent of the thing, > > > > Ummm ... isn't this exactly what's disallowed by 8.5.1(5)? > > Yes, it is. Bob is thinking about cases where a non-discriminant component > is moved by the changing of a discriminant. (I know this because he and I > have had this particular discussion repeatedly.) An implementation like that > is bound to fail, IMHO. On the other hand, an implementation like > Janus/Ada's (in which discriminant dependent components are just descriptors > to the actual data) doesn't have this problem. (There is some complication > determining the correct storage pool to use - think about a discriminant > changing assignment on a subprogram parameter - but its not particularly > hard to get right.) Thanks for replying, Randy. When I saw Adam's note, I then recalled that you and I had had the same discussion some years ago, and I think you pointed out the same paragraph. But by the time I got around to replying to Adam, I couldn't find his note. I may be confused on this issue. The bug in question was years ago, and was in an Ada 83 compiler (not Janus Ada -- as Randy explained above, it doesn't have this bug). I think Randy's description of what I was thinking of is correct. Something like this: type R(D: Natural := 0) is record S: String(1..D); Blah: Integer; end; X: R := (D => 4, S => "abcd", Blah => 5); Y: Integer renames X.Blah; X := (D => 5, S => "ABCDE", Blah => X.Blah); The compiler in question allocated the whole record R on the heap, so the stack variable X just contained an address. When X is assigned D=>5, it needs to grow, so the generated code would move the data and make X point to a different spot. But Y was implemented as the address of X.Blah, which moved, which made Y a dangling pointer. To fix this compiler bug, you would have to implement renaming differently, or else do it like Randy said above (make component S indirect, rather than the whole record R). Many compilers won't tolerate the above example at all -- they will try to allocate 2 billion bytes for X, and crash with Storage_Error. - Bob