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,fb264cdd67c2f20f X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Newsgroups: comp.lang.ada Subject: Re: A smaller self contained test case. Was: Compiler Bug or what I'm doing wrong? References: <05lkrrojfd.fsf@hod.lan.m-e-leypold.de> <1cfjjgsg6wwv4.44snml2yzt42$.dlg@40tude.net> <7sr71erb6j.fsf@hod.lan.m-e-leypold.de> <5v7eb8ink18v$.2y1201vcnkcc.dlg@40tude.net> From: M E Leypold Date: 25 Jun 2006 12:51:15 +0200 Message-ID: <0ifyhtv78c.fsf@hod.lan.m-e-leypold.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Some cool user agent (SCUG) NNTP-Posting-Host: 88.72.230.88 X-Trace: news.arcor-ip.de 1151232311 88.72.230.88 (25 Jun 2006 12:45:11 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news2.google.com!news2.google.com!atl-c05.usenetserver.com!news.usenetserver.com!cycny01.gnilink.net!hwmnpeer01.lga!hwmnpeer01.ams!news.highwinds-media.com!feed.xsnews.nl!feeder.xsnews.nl!feeder1.cambrium.nl!feed.tweaknews.nl!newsgate.cistron.nl!xs4all!news.tele.dk!news.tele.dk!small.news.tele.dk!news-fra1.dfn.de!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news2.google.com comp.lang.ada:5016 Date: 2006-06-25T12:51:15+02:00 List-Id: "Dmitry A. Kazakov" writes: > On 24 Jun 2006 22:22:30 +0200, M E Leypold wrote: > > > I followed Barnes' advice here: "wether it is appropriate to use a > > variant or tagged type, the key consideration is mutability". > > True [mutability of class instances] Handles to tagged types is another way > to have mutable class-wide. > > >> procedure Get_Record is > >> F : File_Type; > >> S : Stream_Access; > >> begin > >> Open (F, Mode => In_File, Name => "tmp-bug3" ); > >> S := Stream (F); > >> for I in 1 .. 400 loop > >> declare > >> R : Customer_Description renames > >> Customer_Description'Input (S); > > > > Oops. My, that is a dirty trick -- but how do I return R? Hm, yes I > > can see how that would work. Perhaps :-). I'll see how I can fit that > > into the database module. > > Hey, it is not a trick, but a nice pattern! I am using it quite often, and > count it for a good style. I didn't know that one could rename function results :-). Never had seen that. But now that I see it, it makes a lot of sense. My experiments indicate that a lot less finalizers/initializers run with that pattern. That is good and I'll keep that in mind. Also, thinking about it, that should be solution to initializing limited values, wich I have been looking for and never foudn it (AFAIK Barnes is silent on that). I assume the following would work (with B_Type being a limited type)? declare B : B_Type renames Make_a_B(...); > Anyway, the following will work as well: Unfortunately all that doesn't remove my original Bug. The original program (not the simplified example) has a more complex data structure and a kind of filesystem/database. If I replace Read/Write by Input/Output there, the bug persists. In the really simple example I submitted, tha bug goes away, but I consider this accidental (due to the Heisenbug nature of initialization- and malloc()-related bugs). When trying to replace the Unbounded_String(s) in the example by Controlled types A_Class and B_Class which print when their finalizes/initializers/asjustment are run, I get mixed, partially non reproducible results: - I had a case where it seemed, that one initializer too many is run. When trying to change the tracing that effect vanished and couldn't be restored. - I had a case where during Read no initializers/finalizers whatever where run, but the discriminant was changed. The finalizer for the non-visible variant part (non-visible with the changed dioscriminant) was run at block exit but on the data content of the visible variant part. All that indicates that the problem in question is not simply a problem ion the order of operations as a surmised before. It looks a bit like a caching problem: When at block exit the runtime examines the discriminant it seems to have retained the old value somewhere and act on that. I hoped, that switching of optimization (-O0) would make that kind of bug go away, but didn't change anything. I'm stuck for the moment. Simple workarounds obviously don't cover the more complex cases (variant parts in varaint parts in variant parts). Either I will have to write IO-procedure manually, or I'll have to change to another compiler. Well. Regards -- Markus