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: a07f3367d7,aba1514f4a1fc450 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Received: by 10.205.130.14 with SMTP id hk14mr2112867bkc.5.1345659512479; Wed, 22 Aug 2012 11:18:32 -0700 (PDT) Received: by 10.180.96.42 with SMTP id dp10mr542814wib.2.1345659512014; Wed, 22 Aug 2012 11:18:32 -0700 (PDT) Path: m12ni126129bkm.0!nntp.google.com!news1.google.com!yt1no39599495wib.1!news-out.google.com!n2ni262726749win.0!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!194.109.133.85.MISMATCH!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!news2.euro.net!news.mixmin.net!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Bill Findlay Newsgroups: comp.arch,comp.lang.ada Subject: Re: Have the Itanium critics all been proven wrong? Date: Wed, 22 Aug 2012 19:18:29 +0100 Message-ID: References: <5021874F.1747D0BF@sonic.net> <46f19bfc-930e-4f06-b5a6-c60f39cfda0c@p14g2000yqk.googlegroups.com> <077b12f6-1196-4b5c-bbdb-04291b1ae616@q22g2000vbx.googlegroups.com> <589825d2-d998-456a-9c37-c8ae13e1e7bc@e29g2000vbm.googlegroups.com> <793f28d5-8d61-48e7-adc8-266356cecd26@cf4g2000vbb.googlegroups.com> Mime-Version: 1.0 X-Trace: individual.net DmbD+0BsxbUC/+i9G+QOPApX8TR54PhYJ1/ueBqpwW6MD5ysj7HUJq5JTzb6HbYMsv Cancel-Lock: sha1:mxLkDW8SM4dL1mV9SSFM5wHnaWU= User-Agent: Microsoft-Entourage/12.33.0.120411 Thread-Topic: Have the Itanium critics all been proven wrong? Thread-Index: Ac2Akod4Sm2RMVg/WUC/fULVipDJ2w== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Date: 2012-08-22T19:18:29+01:00 List-Id: On 22/08/2012 16:59, in article 793f28d5-8d61-48e7-adc8-266356cecd26@cf4g2000vbb.googlegroups.com, "Michael S" wrote: > On Aug 22, 6:06�pm, Brian Drummond wrote: >> On Wed, 22 Aug 2012 07:00:31 -0700, Michael S wrote: >>> On Aug 22, 3:39�pm, Brian Drummond wrote: >>>> On Wed, 22 Aug 2012 03:32:00 -0700, Michael S wrote: >> >> [... discussion of private types exported to module A from B] >> >>>> This puts B in charge of the object lifetimes; if A wants to access a >>>> stale object, expect an exception. >> >>> Exception, if I am lucky. >>> If I am less lucky, the physical place of old auto object is now >>> occupied by new auto object of the same or compatible type and the call >>> to accessor caused silent corruption. >> >> If a module has exported a pointer to an "auto object" then the >> accessibility checks have been circumvented by unchecked_access or >> unchecked_conversion. In which case ... yes, caveat programmer! >> > > My knowledge of Ada is rather rusty :( > Is it correct to say that applying 'access attribute to auto objects > is a syntax error and that the only possible way of getting access to > such objects is by applying 'unchecked_access attribute? No, 'Access is perfectly OK for an auto object, but the object must be explicitly declared as of type "aliased T", and about the only thing you can do with the access value is pass it into an "access all T" pointer (or explicitly unsafely coerce it). If the pointer type is declared in the same scope as the object, or in an enclosed scope, no pointer value of that type can survive leaving the object's scope (modulo explicitly unsafely coercing to a type of wider scope). It is not impossible to hang yourself with Ada - there is quite sufficient rope - but it requires very deliberate and unusual preparation, and won't happen by mere accident or ordinary negligence. > Thinking about it, it makes sense. > 99% of cases of passing pointers to auto object as parameters in C are > not because programmer really wants to pass pointer, but because of > absence of 'out' and 'in out' modes and due to inefficiency of passing > of big objects in C language equivalent of 'in' mode. Exactly so. > Also nearly 100% of uses of pointers to auto object in the local > context are due to [by now quite often false] programmer's believe > that he can optimize better than optimizing compiler. And again, yes. But sometimes the programmer is right about that. 8-) -- Bill Findlay with blueyonder.co.uk; use surname & forename;