From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 8 Sep 93 14:27:24 GMT
From: agate!howland.reston.ans.net!math.ohio-state.edu!cis.ohio-state.edu!news.
sei.cmu.edu!jbg@ucbvax.Berkeley.EDU  (John Goodenough)
Subject: Re: obj'size for constants
Message-ID: <1993Sep8.102724.25070@sei.cmu.edu>
List-Id: <comp.lang.ada>

In article <1993Sep7.181330.3952@ocsystems.com>, kdh@ocsystems.com (Kevin D.
Heatwole - OC Systems Inc.) writes: 

|>   Consider:
|> 
|>        one : constant integer := 1;
|> 
|> and integer'size = 32.  What are legitimate values that an implementation
|> may return for one'size?
|> 
|> I have read AI-00536 and it seems fairly clear that "if X is an object of
|> subtype S, then X'Size >= S'Size" so one'size should equal 32 (at least).
|> But, the LRM states that p'size yields the number of bits allocated to hold
|> the object.  In our implementation, scalar constants are replicated at use 
|> and rarely have any bits allocated to them at runtime (in this case, one
|> would most likely be represented in the hardware instruction (probably as
|> part of the op-code), rather than allocated in data memory).
|> 
|> In reading AI-00536, it doesn't seem that the authors considered this case

This is true.  We were concerned with other issues.

|> The reason I ask this question is that we are maintaining an Ada compiler
|> which returns the actual number of bits reserved for the object in memory
|> (e.g., one'size = 0), but a pesky user has filed a defect indicating that
|> the result should be the same as type'size for constants (e.g., one'size = 3
2).
|> We must fix all reported defects (if legitimate), but I would rather leave
|> the current behaviour as it is.

The short answer is that in this specific case it is certainly legitimate to
return zero for ONE'SIZE if the object is in fact not allocated any space as
an object.  Lawyerly arguments follow.

AI-00536/08 says in the first paragraph of its summary (which also serves as
the official recommendation):

    'SIZE applied to an object yields the number of bits allocated for the
    object.

This just replicates the basic statement in the RM.  The rest of the summary
does not specify what the value of ONE'SIZE should be, because it deals with
the size of objects whose type or subtype size has been specified with a
length clause (not the case for this example) or the size of a type or subtype
when no length clause has been given (irrelevant to this example).  Finally,
the last paragraph of the summary states:

    An implementation shall describe, in Appendix F, how the value of 'SIZE is
    determined for objects, types, and subtypes.

Your implementation can say the value of 'SIZE for objects like constants is
determined based on whether the constant is materialized in storage.

The above is basically the answer to your specific question.  But there are a
few complications.  In particular, the final paragraphs in the discussion
section of the AI do seem to address your case:

    In short, when no size has been specified for a type T or a first named
    subtype T and T is not an unconstrained array type or an unconstrained
    type with discriminants, the following relationships must hold when S is a
    subtype of T and OBJ is declared with the subtype indication S:

	       ...

	    .  OBJ'SIZE >= S'SIZE unless OBJ is a component of a record and a
	       component clause is given for OBJ.  In this case, OBJ'SIZE is th
e
	       number of bits specified in the component clause, and this numbe
r
	       may be smaller than S'SIZE or T'SIZE (see AI-00551).

This part of the discussion was intended to explore the ramifications of the
recommendation and it failed to take into account the freedom to return zero
as the size of an object that is not allocated any space at all, due to
optimizations.  Since the discussion section of an AI has no official force,
this oversight is not too significant.  There is no doubt in my mind that if
'SIZE for constants had been considered explicitly by the ARG, the discussion
in this AI would have been modified to say clearly that zero is an acceptable
value when objects are not allocated any storage at all.

Of course, the AI as currently written says that if the size of a type has
been specified with a length clause, then all objects of the type are
allocated at least the specified number of bits (except in certain record
objects).  I also have no doubt that if optimizations had been considered, the
relevant paragraph of the summary would have been changed to say clearly that
if no space is allocated for an object, OBJ'SIZE should return zero; it was
not the intent of the ARG to require that objects be materialized as a side
effect of specifying the size of the object's type.

Finally, since this analysis hasn't been reviewed or approved by anyone, it
has no official force, but it does reflect my considered opinion of what an
"official" response would be.  I hope this is helpful.

John Goodenough
Chair, Ada Rapporteur Group