Re: Have the Itanium critics all been proven wrong?

[Bill Findlay <yaldnif.w@blueyonder.co.uk>]

On 22/08/2012 16:59, in article
793f28d5-8d61-48e7-adc8-266356cecd26@cf4g2000vbb.googlegroups.com, "Michael
S" <already5chosen@yahoo.com> wrote:

> On Aug 22, 6:06�pm, Brian Drummond <br...@shapes.demon.co.uk> wrote:
>> On Wed, 22 Aug 2012 07:00:31 -0700, Michael S wrote:
>>> On Aug 22, 3:39�pm, Brian Drummond <br...@shapes.demon.co.uk> 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;