Re: Null Range in Unconstrasined Array

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Peter C. Chapin" <pcc482719@gmail.com> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> wrote in 
> news:wcc4ormhe61.fsf@shell01.TheWorld.com:
>
>> Randy's reason applies only if the array is aliased,
>> which the above one is not.  There's no reason the compiler 
>> has to allocate any space for My_Array above.
>> 
>> If we have:
>> 
>>     My_Array : My_Array_Type (1 .. 0);
>>     X : Boolean;
>> 
>> it is entirely possible (likely even) that My_Array'Address = X'Address.
>
>
> Wouldn't it be possible to pass My_Array to a subprogram expecting 
> My_Array_Type?

Yes.

>...The subprogram might consult the bounds on the formal 
> parameter before trying to use the array so sending a null array to such a 
> subprogram is not automatically going to cause a problem. In that case, it 
> seems like My_Array needs to have memory allocated for it to hold 
> information about the bounds.

The called procedure has to have some way to know the bounds.
That's true whether the bounds are 1..0 or 1..100.

There are several ways to implement that.
For example, the procedure could be passed the bounds as separate
parameters, in two registers.  I don't consider that to
be "memory allocated for My_Array", because it is not
allocated when the compiler sees My_Array -- it is allocated
when the compiler sees a call (and separately for each call).
In this case, My_Array'Address = X'Address is likely.

Alternatively, the compiler could allocate the bounds as part
of My_Array, just in case there are some such calls.
In this case, My_Array'Address = X'Address is unlikely.

If the procedure is inlined, the bounds might end up being stored only
in the immediate-value fields of instructions.  Or the entire
procedure call might vanish, because the compiler knows it's
(say) looping through an empty array.

- Bob