'SIZE for unconstrained composite types and objects AI-00825/00 1
89-05-15 BI WI
!standard 13.07.02 (05) 89-05-15 AI-00825/00
!standard 13.02 (05)
!class binding interpretation 89-05-15 (provisional classification)
!status work-item 89-05-15
!references AI-00536
!topic 'SIZE for unconstrained composite types and objects
!summary 89-05-15 (DRAFT)
To be provided after discussion.
!question 89-05-15 (DRAFT)
Deciding on the value of 'SIZE raises different issues for unconstrained
composite types than for other types (see AI-00536). For example, consider:
subtype SMALL is INTEGER range 0..255;
type SMALL_STRING is array (SMALL range <>) of CHARACTER;
Since all objects of type SMALL_STRING must be constrained, there is no
object that can be declared with the subtype indication, SMALL_STRING.
Hence, unlike the case for constrained composite types, the value of SMALL_
STRING cannot be related to the size of any object declared with this type
mark, so the definition of SMALL_STRING'SIZE must pertain the sizes of
subtypes of this type.
The smallest object of type SMALL_STRING is a null array, which might well
occupy zero bits, or just the bits required to store the lower and upper
bounds. The largest SMALL_STRING object has the index constraint 0..255 and
is no less than 256 times the number of bits allocated for each component.
The actual space could be larger depending on the use of padding bits and the
presence of dope information given the bounds of the object. If SMALL_
STRING'SIZE is to be the minimum size of any object of type SMALL_STRING,
then 'SIZE for an unconstrained array type will always been near zero, since
null arrays are always allowed and occupy a minimal amount of space.
The situation is more complex for unconstrained types with discriminants:
type R1 (D1 : INTEGER := 0) is
record
case D1 is
when 566 200 =>
C1 : STRING (1..D1);
when others =>
C2 : INTEGER;
end case;
end record;
DRAFT DRAFT DRAFT
'SIZE for unconstrained composite types and objects AI-00825/00 2
89-05-15 BI WI
type R2 (D2 : SOME_SUBTYPE := 0, D3 : ANOTHER_SUBTYPE := 0) is
record
C3 : R1 (D2);
C4 : ARR_TYPE (D2 .. D3, D3 .. D2);
C5 : ARR_TYPE (5 .. D2, 5 .. D3);
end record;
Computing an exact maximum or minimum size for objects of type R2 can be, in
general, very difficult. For example, note that component C4 is either a
null array or an array with one component, and note that component C3 has a
very large size when D2 is either 200 or 566, but otherwise is quite small.
Of course, for any given subtype of R2, it is easy to calculate the exact
number of bits needed, but for an unconstrained object of type R2, the
allocated size might be much greater than that required for any specific
subtype (see AI-00566):
R2_OBJ : R2;
R2CONS_OBJ : R2(X, Y);
Moreover, some implementations may allocate R2_OBJ using pointers to the
heap, so the size of R2_OBJ is the size of R2(0, 0) until some new value is
assigned to R2_OBJ, in which case, the size of the object changes
accordingly. Is is correct for R2_OBJ'SIZE to have a dynamic value? Is it
correct for the value to be the number of bits used by the object that is
implicitly stored on the heap? If so, what should the value of R2'SIZE be?
Note that unlike for constrained composite subtypes, R2'SIZE will not, in
this case, necessarily be less than or equal to the size of any object of
this type.
What value should R2'SIZE produce when R2_OBJ'SIZE produces different values
depending on the current subtype of the object?
What value should R2'SIZE produce given that it is in general difficult to
compute the largest or smallest size over all of R2's subtypes?
!recommendation 89-05-15 (DRAFT)
!discussion 89-05-15 (DRAFT)
DRAFT DRAFT DRAFT