13.11.3 Default Storage Pools
[Pragma and aspect Default_Storage_Pool specify
the storage pool that will be used in the absence of an explicit specification
of a storage pool or storage size for an access type.]
Name Resolution Rules
is expected to be of type Root_Storage_Pool'Class.
Reason: We considered
having the Standard storage_pool_indicator
resolve to package Standard rather than being an identifier specific
to a pragma. That would eliminate the need for a special check. But it
would be bizarre to have something that could resolve to either an object
or a (single) package, and resolving to package Standard would imply
that the standard pool is an object declared in that package. A storage
pool object must be a variable (see 13.11),
yet preelaborable packages depend on package Standard, which would require
implementers to implement the standard storage pool with Preelaborable_Initialization,
which is an unnecessary restriction.
No declaration of Standard
can ever be use-visible, as the language-defined nonoverloadable definition
of Standard will hide any use-visible declarations. Thus we need only
concern ourselves with eliminating any possible confusion with regard
to immediately visible declarations with the defining_identifier
If the pragma
is used as a configuration pragma, the storage_pool_indicator
shall be either null or Standard
, and it defines the default pool
to be the given storage_pool_indicator null
within all applicable compilation units (see 10.1.5
except within the immediate scope of another pragma
Default_Storage_Pool. Otherwise, [the pragma occurs immediately within
a sequence of declarations, and] it defines the default pool within the
immediate scope of the pragma to be the given storage_pool_indicator either
null or the pool denoted by the storage_pool_name
except within the immediate scope of a later pragma Default_Storage_Pool.
[Thus, an inner pragma overrides an outer one.]
shall not be used as a configuration pragma that applies to a compilation
unit that is within the immediate scope of another pragma
is to prevent confusion in cases like this:
package Parent is
pragma Default_Storage_Pool(...); -- Illegal!
package Parent.Child is
where the Default_Storage_Pool
on Parent.Child would not (if it were legal) override the one in Parent.
The language-defined aspect Default_Storage_Pool may be specified for
a generic instance; it defines the default pool for access types within
an instance. The
expected type for the Default_Storage_Pool aspect is Root_Storage_Pool'Class.
must be a name
that denotes a variable. This aspect overrides any Default_Storage_Pool
pragma that might apply to the generic unit; if the aspect is not specified,
the default pool of the instance is that defined for the generic unit
The Default_Storage_Pool aspect may be specified
as Standard, which is an identifier specific to an aspect (see 13.1.1)
and defines the default pool to be Standard. In this case, there shall
not be a declaration with defining_identifier
Standard that is immediately visible at the point of the aspect specification,
other than package Standard itself.
Otherwise, the expected type for the Default_Storage_Pool
aspect is Root_Storage_Pool'Class and the aspect_definition
shall be a name
that denotes a variable. This aspect overrides any Default_Storage_Pool
pragma that applies might
apply to the generic unit; if the
aspect is not specified, the default pool of the instance is that defined
for the generic unit.
Aspect Description for Default_Storage_Pool:
Default storage pool for a generic instance.
The effect of specifying the aspect Default_Storage_Pool
on an instance of a language-defined generic unit is implementation-defined.
The effect of specifying aspect Default_Storage_Pool
on an instance of a language-defined generic unit.
For nonderived access types declared in places where the default pool
is defined by the pragma or aspect, their Storage_Pool or Storage_Size
attribute is determined as follows, unless Storage_Pool or Storage_Size
is specified for the type:
If the default pool is null
, the Storage_Size attribute is defined
by the language to be zero. [Therefore, an allocator
for such a type is illegal.]
If the default pool is neither null nor
, the Storage_Pool
attribute is that pool.
Otherwise (including when the default pool is specified
as Standard),, there is no default pool;
the standard storage pool is used for the type as described in 13.11
Default_Storage_Pool is the only way to specify the storage pool for
an anonymous access type.
Note that coextensions should be allocated in the same pool (or on the
stack) as the outer object (see 13.11
Storage_Pool of the access discriminant (and hence the Default_Storage_Pool)
is supposed to be ignored for coextensions. This matches the required
finalization point for coextensions.
The default storage pool for an allocator that occurs within an instance
of a generic is defined by the Default_Storage_Pool aspect of the instantiation
(if specified), or by the Default_Storage_Pool pragma that applied to
the generic; the Default_Storage_Pool pragma that applies to the instantiation
It is possible to specify the Default_Storage_Pool aspect for an instantiation
such that allocations will fail. For example, the generic unit might
be expecting a pool that supports certain sizes and alignments, and the
one on the instance might be more restrictive. It is the programmer's
responsibility to get this right.
The semantics of the Default_Storage_Pool aspect are similar to passing
a pool object as a generic formal, and putting pragma Default_Storage_Pool
at the top of the generic's visible part, specifying that formal.
An object created by an allocator
that is passed as the actual parameter to an access parameter may be
allocated on the stack, and automatically reclaimed, regardless of the
This matches the required finalization point for such an allocated object.
Default_Storage_Pool can may
be used with restrictions No_Coextensions and No_Access_Parameter_Allocators
) to ensure that all allocator
use the default pool.
Wording Changes from Ada 83
Incompatibilities With Ada 2005
Pragma Controlled has been dropped from Ada, as it
has no effect in any known Ada implementations and it seems to promise
capabilities not expected in Ada implementations. This is usually not
an incompatibility, as the pragma merely becomes unrecognized (with a
warning) and can be implemented as an implementation-defined pragma if
desired. However, it is incompatible if it is (now) implemented as an
implementation-defined pragma, someone used this pragma in a unit, and
they also used restriction No_Implementation_Pragmas on that unit. In
that case, the pragma would now violate the restriction; but use of this
pragma (which does nothing) should be very rare, so this is not a significant
Extensions to Ada 2005
Wording Changes from Ada 2005
The entire discussion of garbage collection (and especially that of controlled
objects) is deleted. Ada 2012 provides subpools (see 13.11.4
for storage management of objects, including controlled objects, a mechanism
which is much more predictable than garbage collection. Note that no
version of Ada allows early finalization of controlled objects (other
than via the use of Unchecked_Deallocation or Unchecked_Deallocate_Subpool),
so that garbage collection of such objects would be ineffective in the
standard mode anyway.
Extensions to Ada 2012
Wording Changes from Ada 2012
Corrigendum: We now explicitly say that
the behavior of language-defined generic units when given the Default_Storage_Pool
aspect is implementation-defined. Portable code cannot rely on such a
package using a particular pool implementation.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe