* error in index constraints with initial value
@ 2002-04-04 17:25 Thomas Haeckel
2002-04-04 17:41 ` Marin David Condic
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Thomas Haeckel @ 2002-04-04 17:25 UTC (permalink / raw)
Hi,
I've compiled the following procedure with gnat version 2.8.1 and also
3.14p.
1:with Text_IO; use Text_IO;
2:
3:procedure Index_Constraint_Test is
4:
5:type VAR_LINE(LENGTH:INTEGER:=5) is
6:record
7: IMM:STRING(1..LENGTH);
8:end record;
9:
10:NULL_LINE: VAR_LINE(0);
11:TWO_LINE: VAR_LINE(2);
12:XXXX_LINE: VAR_LINE;
13:
14:begin
15: Put_Line("NULL_LINE="&NULL_LINE.IMM&"#");
16: Put_Line("TWO_LINE="&TWO_LINE.IMM&"#");
17: Put_Line("XXXX_LINE="&XXXX_LINE.IMM&"#");
18:end;
I got following runtime error with both gnat versions:
raised STORAGE_ERROR : object too large
This is caused by the variable instantiation XXXX_LINE in line 12.
After the example in LRM 3.6.1(15) this should be allowed.
Also an old Aionix-Ada83-compiler works fine.
Why has the initialization of the index constraint in line 5 no effect
apparently ?
Is this effect a "feature" of gnat or Ada95 ?
How can I do an null-array (length 0, no component) definition at
compile time, to assign an arraysize while runtime ?
Thanks,
Thomas
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: error in index constraints with initial value
2002-04-04 17:25 error in index constraints with initial value Thomas Haeckel
@ 2002-04-04 17:41 ` Marin David Condic
2002-04-04 17:48 ` Toshitaka Kumano
2002-04-04 20:19 ` Frank J. Lhota
2 siblings, 0 replies; 4+ messages in thread
From: Marin David Condic @ 2002-04-04 17:41 UTC (permalink / raw)
The problem is likely to be in:
12:XXXX_LINE: VAR_LINE;
The GNAT compiler allocates for the worst possible case so that if you
assign to XXXX_LINE, it doesn't have to reallocate memory. This is not
really so much a feature of Ada95 as it is a feature of GNAT. IIRC, the old
DEC Ada83 compiler would not have a problem with this and would do the
memory allocation on assignment. Its an implementation decision that is
allowable by the standard.
You could use an access type to VAR_LINE and the "new" allocator to get
around this.
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin.condic@pacemicro.com
"Thomas Haeckel" <thomas_haeckel@web.de> wrote in message
news:21b0043b.0204040925.4654c421@posting.google.com...
> Hi,
>
> I've compiled the following procedure with gnat version 2.8.1 and also
> 3.14p.
>
> 1:with Text_IO; use Text_IO;
> 2:
> 3:procedure Index_Constraint_Test is
> 4:
> 5:type VAR_LINE(LENGTH:INTEGER:=5) is
> 6:record
> 7: IMM:STRING(1..LENGTH);
> 8:end record;
> 9:
> 10:NULL_LINE: VAR_LINE(0);
> 11:TWO_LINE: VAR_LINE(2);
> 12:XXXX_LINE: VAR_LINE;
> 13:
> 14:begin
> 15: Put_Line("NULL_LINE="&NULL_LINE.IMM&"#");
> 16: Put_Line("TWO_LINE="&TWO_LINE.IMM&"#");
> 17: Put_Line("XXXX_LINE="&XXXX_LINE.IMM&"#");
> 18:end;
>
> I got following runtime error with both gnat versions:
> raised STORAGE_ERROR : object too large
> This is caused by the variable instantiation XXXX_LINE in line 12.
> After the example in LRM 3.6.1(15) this should be allowed.
> Also an old Aionix-Ada83-compiler works fine.
> Why has the initialization of the index constraint in line 5 no effect
> apparently ?
> Is this effect a "feature" of gnat or Ada95 ?
> How can I do an null-array (length 0, no component) definition at
> compile time, to assign an arraysize while runtime ?
>
> Thanks,
> Thomas
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: error in index constraints with initial value
2002-04-04 17:25 error in index constraints with initial value Thomas Haeckel
2002-04-04 17:41 ` Marin David Condic
@ 2002-04-04 17:48 ` Toshitaka Kumano
2002-04-04 20:19 ` Frank J. Lhota
2 siblings, 0 replies; 4+ messages in thread
From: Toshitaka Kumano @ 2002-04-04 17:48 UTC (permalink / raw)
Hi,
Thomas Haeckel wrote:
> 5:type VAR_LINE(LENGTH:INTEGER:=5) is
Try to change "Interger" to more range-constraint subtype.
Integer'Range can make "Storage_Error" for most machines.
--
Toshitaka Kumano
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: error in index constraints with initial value
2002-04-04 17:25 error in index constraints with initial value Thomas Haeckel
2002-04-04 17:41 ` Marin David Condic
2002-04-04 17:48 ` Toshitaka Kumano
@ 2002-04-04 20:19 ` Frank J. Lhota
2 siblings, 0 replies; 4+ messages in thread
From: Frank J. Lhota @ 2002-04-04 20:19 UTC (permalink / raw)
The problem with your definition of XXXX_LINE is that you do not constrain
the record variant LENGTH. LENGTH will default to 5, but since it is not
constrained, XXXX_LINE can be assigned a VAR_LINE value of any length, even
LENGTH => Integer'Last! Of course, this requires more space than is
possible, resulting in the blow-up.
There are a couple of ways to handle this properly. If XXXX_LINE really
needs to hold VAR_LINE records of widely varying and arbitrarily long
lengths, you should declare XXXX_LINE as an access value and allocate these
VAR_LINE records from the heap.
Another possible solution is available is we can assume that there is a
reasonable upper limit on the length of a VAR_LINE. We can then use a
subtype to limit the value of LENGTH, so that VAR_LINE has a reasonable
maximum size, e.g.,
subtype Var_Line_Len is Integer range 0 .. 1023;
type VAR_LINE( LENGTH : Var_Line_Len := 5 ) is
record
IMM:STRING(1..LENGTH);
end record;
With this declaration, VAR_LINE will never have a length greater than
Var_Line_Len'Last. With this change, your program should compile.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2002-04-04 20:19 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-04-04 17:25 error in index constraints with initial value Thomas Haeckel
2002-04-04 17:41 ` Marin David Condic
2002-04-04 17:48 ` Toshitaka Kumano
2002-04-04 20:19 ` Frank J. Lhota
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox