From: "Marin David Condic, 561.796.8997, M/S 731-96" <condicma@PWFL.COM>
Subject: warning: Storage_Error will be raised at run-time
Date: 1997/12/15
Date: 1997-12-15T00:00:00+00:00 [thread overview]
Message-ID: <97121515433681@psavax.pwfl.com> (raw)
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. (This seems to be the
case even when you declare an object with a fixed discriminant and
an initial expression. It still wants to allocate for the worst
case, presumably in anticipation of reassignment to the object. Or
is it something else altogether?)
I'd like to not constrain the size of the discriminated record to
some arbitrarily small number via use of a subtype for the
discriminant. Is there a known method of sneaking around this? If
I allocate all objects from the heap dynamically, will it restrict
the space to just what is requested? (Seems like that would have
to handle reassignment too - or is there a language rule I'm
forgetting?) Or is there some option or pragma I've missed which
changes the allocation rules?
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?
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"
===============================================================================
next reply other threads:[~1997-12-15 0:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-12-15 0:00 Marin David Condic, 561.796.8997, M/S 731-96 [this message]
1997-12-15 0:00 ` warning: Storage_Error will be raised at run-time Robert Dewar
1997-12-15 0:00 ` Tucker Taft
-- strict thread matches above, loose matches on Subject: below --
1997-12-16 0:00 Marin David Condic, 561.796.8997, M/S 731-96
1997-12-16 0:00 ` Robert Dewar
1997-12-16 0:00 ` Tucker Taft
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox