Re: Ada 2012 : aliased parameters ?

["Randy Brukardt" <randy@rrsoftware.com>]

"Florian Weimer" <fw@deneb.enyo.de> wrote in message 
news:87mxjaf99i.fsf@mid.deneb.enyo.de...
>* Randy Brukardt:
>
>>> Is it necessary that Element is a discriminant?
>>
>> Yes, because access discriminants have special accessibility rules which
>> happen to have the right effect.
>
> This is unfortunate because it means that this cannot be used to make
> variadic argument list trick safer and less of a hack.

One could argue that variadic arguments are themselves a hack. :-)

This feature is intended for one particular use (and any other uses are a 
happy accident): providing safe user-defined dereferencing. What is needed 
for it to be safe is to prevent any copying of the access value while still 
allowing it to be dereferenced (including assigning into it).

We originally had some syntax to define the accessibility of the returned 
access type, but it was eventually pointed out that access discriminants 
already had the appropriate accessibility. (Anonymous access return types 
also have this same accessibility.) Thus we changed the mechanism to use the 
discriminants rather than inventing a new feature.

The advantage of the aliased parameters is that they eliminate the runtime 
checks by forcing the checks to the call site (where they can be statically 
made 99% of the time).

>> It did, but only for bugs. The access discriminant semantics is from Ada 
>> 95,
>> although it was never defined properly (probably still isn't, although 
>> not
>> for the lack to trying). We've just found a good use for the strange
>> semantics.
>
> I don't think the difference is observable in Ada 95 because you
> couldn't return new objects of limited type.

Could be.

> By the way, how tight are the access level checks?  Is it relatively
> safe to assume that if an Ada 2005 compiler compiles a program which
> makes heavy use of anonymous access types and runs it without
> exceptions, then there are no dangling pointers?  (Ignoring unchecked
> deallocation, of course.)

The intent is that it is impossible to create a dangling pointer if no 
unchecked programming is used. (Unchecked_Deallocation, 'Unchecked_Access, 
Unchecked_Conversion, Address_to_Access_Conversions, abuse of 
Unchecked_Unions, etc.) That goes for all access types (not just anonymous 
ones). The problem, of course, is that it is impractical to do much without 
using one of those things. (I've only succeeded in using 'Access once in one 
of my programs; in all other cases I had to use 'Unchecked_Access.)

We're constantly fixing holes in the model, and it is easy to use the 
unchecked things, so I wouldn't consider it impossible to get a dangling 
pointer. (Personally, I prefer to hide pointers as much as possible, as in 
the container cursors, so that dangling pointer detection becomes much more 
possible, and their creation becomes less likely.)

                                  Randy.