TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Nick Roberts <[log in to unmask]>
Reply To:
Nick Roberts <[log in to unmask]>
Fri, 11 Jul 2003 21:55:24 +0100
text/plain (46 lines)
"Apurva Shukla" <[log in to unmask]> wrote:

> I am a starter in Ada and need certain help regarding arrays. I
> have got a code in which there is a line which says:
> a(11..10) := b(1..0);
> here the arrays a and b are of the same type( i have tried
> using integer ) and the range is (1..10). So my questions are:

> 1. Why is ada compiler not noticing that the array range has
> been violated by saying a(11..10)?

Because the range is null. When the range is null, no check on the bounds is
performed (so the value 11 does not cause an exception to be raised, despite
being outside the bounds of array A).

> 2. And this program runs also but the values are not
> providing any clue of what ada compiler does exactly.

The compiler should do nothing, for the execution of this assignment
statement. It should not actually copy any data (since the length of both
the source expression and target variable is 0), and it should not raise any

I would add the comment that it is essential that Ada defines this
behaviour. The reason why is mainly to do with generic units. It often
occurs that, for a (well-designed) generic unit, there will be certain
(valid and meaningful) instantiations that cause such 'null assignments'. A
program might contain a statement such as:

   A(1+i..N+i) := B(1..N);

This kind of assignment must work properly (and not raise an exception) for
the case when 1..N is a null range (I'm ignoring the possibility of 1+i or
N+i raising an exception). As an example, consider the case where N=0 and

Such statements could all be guarded (by an 'if' statement), but generally
it would be too horrible to do so in practice.

Nick Roberts
Jabber: [log in to unmask] [ICQ: 159718630]