Re: GNAT GPL 2013 bug?

[Adam Beneschan <adambeneschan@aol.com>]

On Friday, August 9, 2013 4:01:21 AM UTC-7, Dmitry A. Kazakov wrote:
 
> > Aren't dispatching access parameters inherently always 'not null' anyway,
> > and the explicit qualifier just an optional readability thing?
> 
> No idea, but since Ada 2005 access T can be null. Is the behavior depends
> on whether the parameter is dispatching?
> 
> So considering:
> 
>    type Q is null record;
>    procedure P (X : access Q) is null;
> 
>    Y : access Q := null;
> begin
>    P (Y); -- This is OK (since Ada 2005)
> 
> Now add "tagged" to Q:
> 
>    type Q is tagged null record;
>    procedure P (X : access Q) is null;
> 
>    Y : access Q := null;
> begin
>    P (Y); -- This is not OK?
> 
> I didn't searched ARM for this, but if indeed so, this is a language bug to
> me.

It was a deliberate design decision.  The big difference in your second example isn't just that Q is now tagged; the big difference is that P has become a dispatching procedure, and it dispatches on the argument X.  Passing null for X wouldn't make any sense--what would it dispatch to?  

In this example:

    type Q is tagged null record;
    package Inner is
        procedure P (X : access Q) is null;
    end Inner;

now X can be null, since P isn't dispatching.  In some of the examples in your later post (like the one where Q is private and the full type is a tagged record), there isn't a problem either, since the procedure isn't dispatching.

It has always been the case since Ada 95 that access parameters used for dispatching may not be null.  In Ada 95, actuals for other access parameters weren't allowed to be null either.  In Ada 2005, the language was changed to allow null for access parameters, *except* for those (controlling parameters) which could be dispatched on.  It was also changed to allow "not null".  I believe there was a dilemma when it came to controlling parameters--those still could not be null, but did they want to explicitly require "not null" on them?  The decision was to make those implicitly "not null", which makes some language rules a bit inconsistent but preserved backward compatibility.

                            -- Adam