Re: gcc/gnat 4.1.1 bug

["Adam Beneschan" <adam@irvine.com>]

M E Leypold wrote:

> > This means that the prefix of MDI.Docks'Range does not statically
> > denote anything, and therefore MDI.Docks'First and 'Last (and therefore
> > 'Range) are not static.  Thus, the subtype of "Side" is *not* a static
> > subtype.
>
> I can see, why that rule has bee introduced. But: Apart from how that
> is formulated in the RM: Either MDI is null, than the dereferencing
> fails and the case will not be executed or it is not null, then refers
> to a range which is fixed at compile time.
>
> It might not be static in the sense of the letter in the RM, but it
> certainly is in effect (uh - am I clear?). So I wonder why the
> restriction (no access type) was introduced.

I think what you're saying is clear.

What's worse, perhaps, is that there's a difference even if no access
type is involved.  The rule in 4.8(14) also means "statically denotes"
doesn't apply to record components, so that in this case:

   type Enum is (e1, e2, e3, e4, e5);
   subtype Enum_Subtype is Enum range e2..e4;
   type Arr is array (Enum_Subtype) of integer;
   type Rec is record
      f1 : Arr;
   end record;

   X : Arr;
   Y : Rec;

   for J in X'Range loop        -- J's subtype is static
   for K in Y.f1'Range loop     -- K's subtype is not static

if my understanding is correct.

However, it's not feasible to expect the language designers to handle
every little case and combination of cases and combination of
combinations of cases so that things do what you expect, all the time.
Any change to the definition of "staticness" is going to have a
potential impact on approximately 6.023*(10**23) other places in the
RM, and all of them would need to studied before any change can be
made.  And believe me, the amount of work the language designers
already do is incredible, as it is.


> > (In Ada 95, MDI is not allowed to be null; in Ada 2005, it is.  Perhaps
>                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Why that?

Anonymous access types were added in Ada 95, and the only places they
were allowed were in subprogram parameters and discriminants.  In both
cases, they were added for a specific purpose for which named access
types were unsuitable, and null values didn't need to be handled for
those purposes.  For Ada 2005, anonymous access types were further
generalized and allowed in more places,
and it was decided it would be a good idea to allow null values; the
best solution involved changing the definition of access parameters so
that null values were allowed by default.  If you're interested in more
details, check out
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00231.TXT .

                                 -- Adam