Re: System.Address'Size - not a static integer expression?

[dewar@gnat.com (Robert Dewar)]

Wes Groleau <wesgroleau@despammed.com> wrote in message news:<3CBAEE01.D17C2DB0@despammed.com>...

> I do not recall ever posting that it was a record
> type.  Just that it was rejected and that I found
> (or my faulty memory says I found) something saying
> 'Size was non-static.  The same memory does not think
> it was a record type.

Well this thread was started by a note about a record type.
We really can't deal with Wes' vague memory that there was
a problem with a 'Size reference that he is sure APEX and
GNAT were wrong to reject, but he can't remember exactly
what it was :-)

> 'Size DOES return a scalar.  Therefore, if the prefix
> is static and non-scalar, 4.9 (7) says 'Size on it is
> static.

No, that's not what 4.9(7) says (let's have it again): 

    7  an attribute_reference that denotes a scalar value, 
       and whose prefix denotes a static scalar subtype;

I don't see why you have trouble reading this, it clearly
applies ONLY to static scalar subtypes, and thus does NOT
apply if the prefix denotes a static non-scalar subtype
(the only case of this is a static string subtype and indeed 'Size
applied to such a subtype is not static:

    1. package t is
    2.    subtype r is string (1 .. 10);
    3.    a : constant := r'size;
                           |
       >>> non-static expression used in number declaration
    4. end;

This diagostic from GNAT is indeed correct.

> That does not prove no other paragraph says
> otherwise.  You say no, and you are a generally reliable
> source.  I do not have the time to look for proof that
> my memory is not as faulty as you say.

Whether you have time or not is irrelevant, there is no
such proof, so you will just be wasting your time looking
for it. The principles behind this design are quite clear
so there are no surprised in the interpretation I am
clarifying here. What would be MOST surprising is if 
there *were* a statement corresponding to your memory,
since it is obviously evident that such a statement would
be in error, given the fundamental design criteria for
the language here.

> For now, I have
> no doubt or uncertainty, and certainly no fear.  So 
> perhaps FUD is the wrong term.

FUD is not what you feel, it is the impression that may
be created (gee Ada experts disagree on what the rules of
static expressoins are ...). Well they don't disagree, the
rules are clear and it is important for Ada programmers
to know and understand these rules :-)