From: vilot@wanginst.UUCP (Michael Vilot)
Subject: Re: Elaboration of Parameterised Record Types
Date: Sun, 9-Nov-86 14:37:19 EST [thread overview]
Date: Sun Nov 9 14:37:19 1986
Message-ID: <553@wanginst.UUCP> (raw)
In-Reply-To: 386@cernvax.UUCP
In article <386@cernvax.UUCP> paul@cernvax.UUCP writes:
>
[ a reference from the Vax-Ada Programmer's Run-time Reference Manual]
>However, this seems to conflict with the ARM (Ada Reference Manual) ...
[ Section 7.6 ]
>
> max_possible_string : CONSTANT:=some_value; --Implem defined
> SUBTYPE index IS INTEGER RANGE 0..max_possible_string;
> TYPE text(this_string_maximum : index) IS
> RECORD
>
> "From a user's point of view, a TEXT is a variable length string. Each
> TEXT object has a maximum length, which must be given when the object is
> declared, and a current value, which is a string of some length between
> zero and the maximum."
> ^^^^^^^
>
>Which maximum??? Dec have assumed max_possible_string. But if this should
>be so, why is it necessary to declare, and supply a value for,
>"this_string_maximum"?
>
>On the contrary, it would appear that "this_string_maximum" is what the
>(admittedly ambiguous) ARM intended to say.
>
>My question therefore is:
>Is my understanding faulty or is my NUMERIC_ERROR the result of a coding
>bug in the DEC Vax-Ada compiler, based on a DEC misinterpretation of the
>ARM at this point? I would have thought that DEC should allocate storage
>for the record according to the value of the parameter
>"this_string_maximum" and not according to the type of
>"this_string_maximum".
>
>In practice, many programs will work under either interpretation and will
>give the same external behaviour. Internally however, the DEC
>interpretation allocates much more space. Lastly, the DEC interpretation
>cannot cope with examples such as the one below.
The DEC implementation assigns 'LENGTH according to the BASE type, not
the subtype. Hence the over-allocation of storage.
The real workaround (on DEC Ada) is to use a named number, and not
rely on the attribute.
(Portable? Of COURSE it's portable!
It works on any DEC implementation! :-)
--
Michael J. Vilot ...!decvax!wanginst!vilot (UUCP)
Wang Institute of Graduate Studies vilot%wanginst@CSNet-Relay (CSNet)
Tyng Road, Tyngsboro, MA 01879 MVilot@ADA20 (ARPA)
next prev parent reply other threads:[~1986-11-09 19:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
1986-11-03 17:24 Elaboration of Parameterised Record Types paul
1986-11-05 17:33 ` Mark Biggar
1986-11-09 19:37 ` Michael Vilot [this message]
-- strict thread matches above, loose matches on Subject: below --
1986-10-08 13:06 Elaboration of parameterised record types paul
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox