Re: warning: Storage_Error will be raised at run-time

[stt@houdini.camb.inmet.com (Tucker Taft)]

Marin David Condic, 561.796.8997, M/S 731-96 (condicma@PWFL.COM) wrote:

:     Maybe this one has been dealt with before. Using GNAT (GNAT 3.09 -
:     Sun Unix) I compile the attached code and get the following error
:     messages:

: procedure Test is

:     type Variant_Type (Size : Natural := 0) is record
:         Count    : Natural ;
:         Table    : String (1..Size) ;
:     end record ;

:     Variant : Variant_Type ;
: begin
:     null ;
: end Test ;

: test.adb:5:31: warning: creation of object of this type may raise Storage_Error
: test.adb:8:05: warning: Storage_Error will be raised at run-time

:     My best guess is that the implementation takes a look at the
:     "(Size : Natural := 0)" part and decides that it needs to allocate
:     1..Natural'Last bytes for the Table field of every object of type
:     Variant_Type. I can see how this would make it simple to handle
:     assignments to objects of type Variant_Type since they would have
:     already allocated memory for the worst case scenario. This seems
:     like a bad implementation choice in that, while it may be very
:     fast, doesn't allow the user much leeway. 

The alternative is to use the heap implicitly when an assignment
needs to enlarge the object.  This approach was adopted by Alsys
under some conditions in their Ada 83 product, and something similar
is supported by RR (and Meridian Ada 83) by using a level of indirection for 
nested arrays, but most other vendors did not embrace this approach.
I believe the main reason is that implicit use of the heap, particularly
as a side effect of a relatively "benign" looking operation like
assignment, is a no-no in a real-time/safety-critical language.

In Ada 95, if you want this kind of automatic "growing" data structure,
then you can program it using controlled types.  That seems like
a better solution to me, because it gives the programmer full,
explicit control over any use of the heap.

: ...
:     While this sort of static allocation may be simple to implement
:     and fast at run time, it seems to defeat a major purpose of
:     discriminated records: the ability to allocate just what you need
:     at run time to accomodate widely varying space demands. Otherwise,
:     why not just go with a fixed size array in the record since that's
:     what you're going to get anyway?

The purpose of discriminated records is not so much to accomodate individual
growing objects, but rather to accommodate multiple objects of different 
sizes, which are nevertheless all of the same type.  

Furthermore, given our recent news thread on the implicit overhead
of holey enumeration types, you can be sure someone would be complaining
about the implicit overhead of assigning to unconstrained discriminated 
records.  Implicit overhead is almost always bad news, IMHO.
If there is to be overhead, the programmer ought to be explicitly writing
and controlling the implementation of that "overhead" computation.

:     MDC

: Marin David Condic, Senior Computer Engineer     Voice:     561.796.8997
: Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600  Fax:       561.796.4669
: West Palm Beach, FL, 33410-9600                  Internet:  CONDICMA@PWFL.COM
: ===============================================================================
:     Glendower: "I can call spirits from the vasty deep."
:     Hotspur: "Why so can I, or so can any man; but will they come when
:     you do call for them?"
:         -- Shakespeare, "Henry IV"
: ===============================================================================

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA