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,a88e582de42cdc9b X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!club-internet.fr!feedme-small.clubint.net!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Bug in Ada (SuSe 10.2) ? Date: Tue, 26 Feb 2008 14:53:28 -0600 Organization: Jacob's private Usenet server Message-ID: References: <0_mdna0iHpIsCifaRVnzvQA@telenor.com> <3a281192-2744-4110-9fc1-90c155c9436b@d4g2000prg.googlegroups.com> <48277611-402f-4622-be05-6edddf6dd56a@o10g2000hsf.googlegroups.com> <624tcvF21i3nvU1@mid.individual.net> <2630d99b-1578-4d79-ac9c-64c00c203b77@e60g2000hsh.googlegroups.com> <69019a65-736e-48ee-bd9f-4c29cd7fc88f@72g2000hsu.googlegroups.com> <48a0a0c4-7b79-42dc-b541-7a68693bdd4c@e41g2000hsc.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1204059263 19247 69.95.181.76 (26 Feb 2008 20:54:23 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 26 Feb 2008 20:54:23 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Xref: g2news1.google.com comp.lang.ada:20108 Date: 2008-02-26T14:53:28-06:00 List-Id: wrote in message news:48a0a0c4-7b79-42dc-b541-7a68693bdd4c@e41g2000hsc.googlegroups.com... > On Feb 25, 4:32 pm, "Randy Brukardt" wrote: > > I spend so much time in the language-lawyer cave (which requires only formal > > terminology) that I can get confused by informal terminology -- especially > > that which is not used in the standard. (Yes, I realize you found a mention > > of it in a non-normative introduction paragraph, but of course I hardly ever > > read those...) > > ... > > Net-net I tend to forget about the accessibility checks on anonymous access > > parameters, because if you encounter them you probably are doing something > > bad (using anonymous access parameters). > > If you are suggesting that the prevention of dangling pointers (into the stack) > is simply non-normative flowery language intended to be ignored or forgotten, > then I disagree. I think it is a fundamental language invariant that users > should be able to rely on to prevent the worst kind of programming errors > (scribbling on arbitrary memory). Not at all. I'm saying that for the dynamic (only) checks, the "cure" is as bad as the "disease". The static checks that you get with named access types don't have the problem with the "cure" being a problem. OTOH, in practice, I find that I have to turn-off all of those checking 99% of the time I use 'Access. (OT3H, I don't use 'Access or access types themselves that much, and most of the access types I do use are heap-allocated or "safe pointers" by virtue of being managed by controlled types.) ... > Paragraph 3 of 3.10.2, which _is_ normative, repeats the invariant: > "The accessibility rules, which prevent dangling references ...". > And the Ada 95 Rationale repeats it as well in Section 3.7, paragraph 3, > which says: "An additional accessibility check is performed to ensure > that the lifefime of the designated subprogram or object will not end > before that of the access type, eliminating the possibility of > dangling references." The Rationale is never normative, so that's irrelevant. 3.10.2(3) is marked in the AARM as a redundant introductory paragraph, meaning that the authors of the RM considered it non-normative. (Yes, it is "technically" normative, but since it is using terms that are undefined in the RM, it doesn't have any meaning.) > > You are using anonymous access parameters to achieve the effect. You are > > quite correct that this is easy to do. That is in fact the problem: it is > > easy to get a Program_Error from passing the "wrong" thing to a subprogram > > that has an anonymous access parameter. > > You are completely missing the point. The simple examples provided show > that it is _not_ so easy to get a Program_Error where one is expected. Surely the program should either be rejected or raise Program_Error. But I'd have to spend an hour reading the accessibility rules to figure out which of those is correct answer. For the record, Janus/Ada rejects your program at compile-time with an accessibility error (pointing at Slats.Altitude'Access). I think that's because the component dereference (remember that this is actually Slats.all.Altitude'Access) drops the "special" accessibility of an anonymous access parameter, and the normal accessibility will fail (as the parameter is more nested than Int_Access). I think that is correct, but in order to be sure, I'd have to spend an hour reading through the accessibility rules (and you'd have to pay me to do that). > > Anyway, I'm pretty sure this is getting wildly off-topic. > > To bring it back on topic, an unsuspecting Ada programmer will be quite > surprised to see overflow checks and stack checks not performed by default > in some cases, and will be equally surprised to see accessibility checks > not performed by default in some cases. For overflow and stack checks, > there is a rather simple solution involving specifying default flags in > the project file. But for accessibility checks, I do not know of any > similar solution. Not performing accessibility checks is simply a bug. The only thing you need to worry about there is sending a bug report to your compiler vendor - it's not a matter of turning them on or off. Randy.