Re: Task entries and access to subprograms.

["Alex R. Mosteo" <devnull@mailinator.com>]

Randy Brukardt wrote:
> "Alex R. Mosteo" <devnull@mailinator.com> wrote in message
> news:4254E00C.30908@mailinator.com...
> 
>>Jeffrey Carter wrote:
>>
>>>Alex R. Mosteo wrote:
>>>
>>>
>>>>type AInt is access all Integer;
>>>>type Code is access procedure;
>>>
>>>
>>>>   entry Two (I : AInt); -- No complaint. Legal?
>>>
>>>
>>>This was legal in Ada 83, and that wasn't changed by Ada 95.
>>>
>>>
>>>>   entry Four (C : Code); -- No complaint.
>>>
>>>
>>>There's a difference between access parameters and parameters of an
>>>access type.
>>
>>Yep. I just feel a bit disturbed when something with a so easy
>>workaround is forbidden.
> 
> 
> Workaround, yes. But these things aren't at all the same, which is obvious
> if you think about all of the implications. (I know Bob has given the actual
> reason for the rule, but his explanation is more for language lawyers.)
> 
> Consider the two similar subprograms declared in a library package
> specification:
> 
>     type Acc_Int is access Integer;
>     procedure One (P : Acc_Int);
>     procedure Two (A : access Integer);
> 
> On the surface, these appear the same. But they have very different
> accessibility rules. That's easy to see when you make a call:
> 
>     procedure Test is
>         Foo : aliased Integer;
>     begin
>         One (Foo'Access); -- Illegal! Fails accessibility check.
>         Two (Foo'Access); -- OK
>     end Test;
> 
> Any accessibility checks needed will be done in the body of Two, while for
> One, they're done at the point of the call.

I see. One thing I've never fully understood (and I'm ashamed to admit 
it, since I've read and forgotten the rationale at least a couple of 
times) is why One (Foo'Access) is illegal in your example. This gives 
multiple headaches (say, using Unchecked_Access :)) in situations who 
are clearly void of risk.

I think these rules have been somewhat relaxed in 0Y, to add to my 
confusion, but at least now I don't find so many unexpected failed 
checks. It may be simply that the "not null access" moves the check out 
as in your Two example, but I must reread it (both 95 and 0Y).

Thanks!

> 
> Bob's point is that the standard implementation of the accessibility check
> won't work for an entry; and there is no other obvious
> no-distributed-overhead implementation available, thus writing the anonymous
> parameter with its complicated accessibility is prohibitied. (You could
> implement the check with a fully dynamic accessibility level, but this would
> have a cost on every scope entrance and exit, and that would be too much to
> swallow.)
> 
> Hope this makes it clear. (One could argue that the accessibility rules
> shouldn't have been different, but that's water under the dam at this
> point.)
> 
>                                    Randy.
> 
> 
> 
>