From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,903f8471df09a778,start
X-Google-Attributes: gid103376,public
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
Message-ID: <97121515433681@psavax.pwfl.com>#1/1
X-Deja-AN: 298490298
Sender: Ada programming language <INFO-ADA@LISTSERV.NODAK.EDU>
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-VMS-To: SMTP%"INFO-ADA@VM1.NODAK.EDU"
X-VMS-Cc: CONDIC
Newsgroups: comp.lang.ada
Date: 1997-12-15T00:00:00+00:00
List-Id: <comp.lang.ada>


    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"
===============================================================================