Re: Warning: accessibility check failure with GNAT GPL 2013

[Adam Beneschan <adambeneschan@aol.com>]

On Monday, October 28, 2013 9:13:41 AM UTC-7, Georg Bauhaus wrote:
> On 28.10.13 16:49, Dmitry A. Kazakov wrote:
> 
> > Use a named access type instead. E.g.
> 
> >    type Cyclic_Thread_Ptr is access all Cyclic_Thread:
 
> 2nd. And consider dropping "all" from the above type
> declaration, if possible. In your example, all pointers
> point to tasks of type Cyclic_Thread that were created
> by an allocator, so "all" is not needed. (Because you
> do not store the 'Access of some "non-heap" task object
> in some pointer variable.)

Although the example may not use any objects that aren't created by an allocator, the question is whether there's any possibility that a programmer *might* want to use the access type to refer to aliased variables or other non-allocated objects later.  If we know that, by the *nature* of the access type and what it's supposed to represent, that having it refer to aliased variables would be unacceptable or cause problems, then don't include "all".  But otherwise I think it's best to include "all".  I include "all" routinely since I haven't written an access type definition where I thought that those access objects *must* refer to heap-allocated objects in all cases.  (If Ada 95 had been designed from scratch, it would have been better to provide an additional keyword to designate access types that must be heap-allocated, if a distinction had to be made at all.  But they were considering the possibility that a pool-specific access type would be represented as a pool-relative offset rather than as an address, and that there could be Ada 83 compilers already doing that.)

                                -- Adam