Version 1.1 of acs/ac-00178.txt

Unformatted version of acs/ac-00178.txt version 1.1
Other versions for file acs/ac-00178.txt

!standard 13.11.1(3/2)          09-10-22 AC95-00178/01
!class confirmation 09-10-22
!status received no action 09-10-22
!status received 09-05-29
!subject 'Max_Size_in_Storage_Elements on class-wide types
!summary
!appendix

From: Adam Beneschan
Date: Friday, May 29, 2009  12:09 PM

!topic 'Max_Size_In_Storage_Elements on class-wide type??
!reference RM 13.11.1, K(145)
!from Adam Beneschan 09-05-29
!discussion

My entry in the competition for "least important AI ever":

The definition of S'Max_Size_In_Storage_Elements says it applies
to any subtype S, with no restriction to specific types. But
shouldn't it be restricted to specific types? There's no way to
return a meaningful result for class-wide types.

****************************************************************

From: Bob Duff
Date: Friday, May 29, 2009  12:33 PM

> My entry in the competition for "least important AI ever":

;-)

> The definition of S'Max_Size_In_Storage_Elements says it applies to
> any subtype S, with no restriction to specific types.  But shouldn't
> it be restricted to specific types?  There's no way to return a
> meaningful result for class-wide types.

I think that would introduce a generic contract model problem (e.g. generic
formal private type with unknown discriminants, actual is class-wide).

Anyway, returning 2**32-1 on a 32-bit machine seems like a reasonable choice.
That number is guaranteed to be larger than the largest allocatable class-wide
object.  Adjust the number for different address-space sizes.

****************************************************************

From: Steve Baird
Date: Friday, May 29, 2009  12:47 PM

Agreed.

The situation with a class-wide type isn't really very different than the
situation with any potentially-enormous type, such as

    type T is array (Positive range <>, Positive range <>,
               ..., Positive range <>) of Integer;

****************************************************************

From: Randy Brukardt
Date: Friday, May 29, 2009   1:37 PM

...
> Anyway, returning 2**32-1 on a 32-bit machine seems like a reasonable
> choice.
> That number is guaranteed to be larger than the largest allocatable
> class-wide object.  Adjust the number for different address-space
> sizes.

Indeed, that is all any implementation has to do for any type. There is no
requirement to return the smallest maximum, after all (and I fail to see how it
could be enforced anyway). An implementation that always returned 2**32-1 for
this attribute would be completely correct.

Implementers probably will want to do better when they can, but it's not worth
spending much effort on: return 2**32-1 unless the subtype is specified,
constrained, and contiguous. (It's not clear to me that this attribute has any
value at all unless the object in question is going to be allocated in one
piece. Who cares that this type will take 8_000 bytes maximum if it is allocated
in 10 allocations of no more than 1_000 bytes at a time? S'Contiguous might be a
worthwhile attribute in order to determine if 'Size, 'Max_Size, etc. really are
meaningful.)

****************************************************************


Questions? Ask the ACAA Technical Agent