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,7a3b1c6915ea1273 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Received: by 10.68.196.130 with SMTP id im2mr8005340pbc.3.1326731755330; Mon, 16 Jan 2012 08:35:55 -0800 (PST) Path: lh20ni189168pbb.0!nntp.google.com!news2.google.com!postnews.google.com!34g2000yqm.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: How many Ada compiler bugs are here? Date: Mon, 16 Jan 2012 08:35:55 -0800 (PST) Organization: http://groups.google.com Message-ID: References: <01dd6341-9c3c-4dcb-90f8-6ac66c65eb66@z1g2000vbx.googlegroups.com> <491fa855-f420-4701-a51a-39ac5a0cb63c@p42g2000vbt.googlegroups.com> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 X-Trace: posting.google.com 1326731755 6941 127.0.0.1 (16 Jan 2012 16:35:55 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 16 Jan 2012 16:35:55 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: 34g2000yqm.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: ARLUEHNKC X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618; .NET4.0C),gzip(gfe) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-01-16T08:35:55-08:00 List-Id: On Jan 14, 2:20=A0am, Maciej Sobczak wrote: > On Jan 13, 1:21=A0am, "Randy Brukardt" wrote: > > > > 3. Logically, Tmp is never created, because Make_T raises an > > > exception. Somehow some object is finalized. Apparently it is Tmp, > > > which should not exist. > > > 4. Somehow Tmp.initialized =3D True, even though its default value is > > > defined to be False. > > > I'm not sure if these are actually bugs or not; the fact that Adjust is > > being called for a limited object means to me that nothing that happens > > afterwards makes any sense > > Adjust is not called, but I have defined it to check if that's the > case. > Still, Adjust is not the biggest issue here, neither is the > requirement for the return statement. > The biggest issue is that the compiler fails to initialize some object > (even ignoring the statically provided field initializers) and yet > considers it to be worthy finalization - and the Finalize operation > has absolutely no line of defense against this. This is a *very* > serious problem. > I have found it, because my program was crashing. > And since this relates to the very fundamentals of the object model, > this bug is not to be ignored. I can live with the rest, but this one > is really serious. I think what Randy was getting at--and I concur with this--is that if you can create a *legal* program that has the bug you're concerned about (i.e. one that does not try to override a non-existent Adjust), then it's a serious problem and you should definitely report it. But if you can't, I wouldn't worry about it. You're probably thinking that you've run across a serious problem in the object model that's **independent** of the Adjust visibility issue. But to me, there's a good chance that this problem is intertwined with the Adjust problem, not independent of it. That's because as a compiler developer myself, I'm aware of the kind of special things compilers need to do to handle Controlled and Limited_Controlled. If something goes wrong with that, I can easily imagine how this could lead to all sorts of other things going wrong. -- Adam