7.3 Storage_Size Clauses

For tasks, the Storage_Size clause specifies the amount of space to be allocated for the task stack. This cannot be extended, and if the stack is exhausted, then Storage_Error will be raised (if stack checking is enabled). Use a Storage_Size attribute definition clause, or a Storage_Size pragma in the task definition to set the appropriate required size. A useful technique is to include in every task definition a pragma of the form:

        pragma Storage_Size (Default_Stack_Size);

Then Default_Stack_Size can be defined in a global package, and modified as required. Any tasks requiring stack sizes different from the default can have an appropriate alternative reference in the pragma.

You can also use the -d binder switch to modify the default stack size.

For access types, the Storage_Size clause specifies the maximum space available for allocation of objects of the type. If this space is exceeded then Storage_Error will be raised by an allocation attempt. In the case where the access type is declared local to a subprogram, the use of a Storage_Size clause triggers automatic use of a special predefined storage pool (System.Pool_Size) that ensures that all space for the pool is automatically reclaimed on exit from the scope in which the type is declared.

A special case recognized by the compiler is the specification of a Storage_Size of zero for an access type. This means that no items can be allocated from the pool, and this is recognized at compile time, and all the overhead normally associated with maintaining a fixed size storage pool is eliminated. Consider the following example:

        procedure p is
           type R is array (Natural) of Character;
           type P is access all R;
           for P'Storage_Size use 0;
           --  Above access type intended only for interfacing purposes
     
           y : P;
     
           procedure g (m : P);
           pragma Import (C, g);
     
           --  ...
     
        begin
           --  ...
           y := new R;
        end;

As indicated in this example, these dummy storage pools are often useful in connection with interfacing where no object will ever be allocated. If you compile the above example, you get the warning:

        p.adb:16:09: warning: allocation from empty storage pool
        p.adb:16:09: warning: Storage_Error will be raised at run time

Of course in practice, there will not be any explicit allocators in the case of such an access declaration.