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.189.202 with SMTP id gk10mr497092pbc.4.1326418073396; Thu, 12 Jan 2012 17:27:53 -0800 (PST) Path: lh20ni175701pbb.0!nntp.google.com!news2.google.com!postnews.google.com!n39g2000yqh.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: How many Ada compiler bugs are here? Date: Thu, 12 Jan 2012 17:26:34 -0800 (PST) Organization: http://groups.google.com Message-ID: <98adc34c-deed-4190-9e10-755cb886984f@n39g2000yqh.googlegroups.com> References: <01dd6341-9c3c-4dcb-90f8-6ac66c65eb66@z1g2000vbx.googlegroups.com> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 X-Trace: posting.google.com 1326418073 17325 127.0.0.1 (13 Jan 2012 01:27:53 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 13 Jan 2012 01:27:53 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: n39g2000yqh.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-12T17:26:34-08:00 List-Id: On Jan 12, 4:21=A0pm, "Randy Brukardt" wrote: > > 2. The return statement in Make_T should not be required, because it > > is unreachable anyway. > > Ada requires all functions to have a return statement. 6.5(5/2). This was= an > Ada 83 rule; we've discussed removing it, but the feeling was that it > catches as many errors as it creates, and we just couldn't justify a chan= ge > to the language that didn't seem to be an obvious improvement. (In my > personal work, it has been about 50-50 as to whether it helps or hinders.= ) > > So the requirement for a return statement is not a bug, it's a language > rule. Maybe it would be helpful to remove the requirement for functions whose last statement is a RAISE statement, so that stubs for functions that aren't supposed to be called or aren't yet implemented don't have to have the useless RETURN. That way, you'd still catch most of the errors that get caught by the rule, if not all of them. I've written code where stub functions call some sort of error procedure that performs a RAISE, and I would have to put a dummy RETURN after the RAISE, which always annoyed me. The change I described wouldn't entirely fix that, since the function body ends with a procedure call statement instead of a RAISE statement. But at least I could add a dummy "raise Program_Error;" at the end instead of trying to write a return statement to cook up some value. But then again, with extended returns, you don't need to cook up a value. The code: -- needed to please the compiler: return (Ada.Finalization.Limited_Controlled with others =3D> <>); could be written more simply as return Dummy : T; -- Adam -- Adam > > > 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 from a formal language perspective, so you can= 't > really say if there is a bug. Garbage-in, garbage-out! Does the same thin= g > happen without Adjust being defined? That would seem more like a bug. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 Randy.