Null Range in Unconstrasined Array

Null Range in Unconstrasined Array

[Rick]

If I have an unconstrained array type 'My_Array_Type' and declare an
instance of it as:

My_Array : My_Array_Type (1 .. 0);

then the LRM tells me it is a null range:

3.5 (4): A range with lower bound L and upper bound R is described by
“L .. R”. If R is less than L, then the range is a null range, and
specifies an empty set of values.

What, exactly, is My_Array (forgive the language) pointing to?
Is any memory allocated to My_Array?

--------------------------------------------
Rick Duley
North Perth,
Western Australia
--------------------------------------------

Re: Null Range in Unconstrasined Array

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]

"Rick" <rickduley@gmail.com> wrote in message 
news:f237670b-ade0-461f-9d02-5eff803e91bc@p10g2000prm.googlegroups.com...
>If I have an unconstrained array type 'My_Array_Type' and declare an
>instance of it as:
>
>My_Array : My_Array_Type (1 .. 0);
>
>then the LRM tells me it is a null range:
>
>3.5 (4): A range with lower bound L and upper bound R is described by
>�L .. R�. If R is less than L, then the range is a null range, and
>specifies an empty set of values.
>
>What, exactly, is My_Array (forgive the language) pointing to?
>Is any memory allocated to My_Array?

That's a question that the ARG decided not to answer in general. (It matters 
for aliased objects and "=" of accesses to such objects). We agreed to not 
decide (see AI95-00350-1, voted No Action). It seems silly to require 
allocating memory for objects with no components, but some people think that 
it is important that access type compare unequal. Thus there was no 
agreement on clarifying the wording.

So you'll have to look to see what your particular compiler does.

                                                              Randy.

Re: Null Range in Unconstrasined Array

[Adam Beneschan]

On Aug 31, 6:28 pm, Rick <rickdu...@gmail.com> wrote:
> If I have an unconstrained array type 'My_Array_Type' and declare an
> instance of it as:
>
> My_Array : My_Array_Type (1 .. 0);
>
> then the LRM tells me it is a null range:
>
> 3.5 (4): A range with lower bound L and upper bound R is described by
> “L .. R”. If R is less than L, then the range is a null range, and
> specifies an empty set of values.
>
> What, exactly, is My_Array (forgive the language) pointing to?
> Is any memory allocated to My_Array?

Most likely, no.  Randy gave a reason why a compiler might want to
allocate a little bit of space for the array; but even if it does,
it's memory that will never be used.  Any attempt to refer to My_Array
(X), no matter what X is, will raise Constraint_Error.

                                    -- Adam

Re: Null Range in Unconstrasined Array

[Robert A Duff]

Adam Beneschan <adam@irvine.com> writes:

> On Aug 31, 6:28�pm, Rick <rickdu...@gmail.com> wrote:
>> If I have an unconstrained array type 'My_Array_Type' and declare an
>> instance of it as:
>>
>> My_Array : My_Array_Type (1 .. 0);
>>
>> then the LRM tells me it is a null range:
>>
>> 3.5 (4): A range with lower bound L and upper bound R is described by
>> �L .. R�. If R is less than L, then the range is a null range, and
>> specifies an empty set of values.
>>
>> What, exactly, is My_Array (forgive the language) pointing to?

Well, arrays don't "point".

>> Is any memory allocated to My_Array?
>
> Most likely, no.  Randy gave a reason why a compiler might want to
> allocate a little bit of space for the array; but even if it does,
> it's memory that will never be used.

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.
Randy's concern about access values does not apply to addresses.

Usually, empty arrays are not statically known to be empty,
though.  In that case, some space might be used to store
the bounds.

>...Any attempt to refer to My_Array
> (X), no matter what X is, will raise Constraint_Error.

Right.

- Bob

Re: Null Range in Unconstrasined Array

[Peter C. Chapin]

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? 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.

Peter

Re: Null Range in Unconstrasined Array

[Robert A Duff]

"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

Re: Null Range in Unconstrasined Array

[Adam Beneschan]

On Sep 6, 5:41 am, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
> 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.

To elaborate on this a bit further: Suppose you define a record type
for reading a file with Ada.Direct_IO, that looks something like this:

  type Employee_Data is record
      Name     : String (1 .. 50);
      Address1 : String (1 .. 40);
      Address2 : String (1 .. 40);
      City     : String (1 .. 30);
      State    : String (1 .. 2);
      ...
  end record;

(Reminds me of my COBOL programming days...)  Anyway, it would be very
unexpected for the compiler to put two extra integers in the record
for each of these strings, and it would mess up your file I/O.  But
you have to have the ability to pass any of those fields to a
subprogram with a parameter type "String", and the bounds have to be
passed to the subprogram somehow.  I think it's most likely that the
bounds will be passed separately, as Bob suggested, either by passing
them in separate registers, creating a three-word temporary structure
that contains the bounds and a pointer to the data and passing the
address of that structure (with that structure disappearing after the
subprogram returns), creating a two-word structure with the bounds and
passing the address of that in a register, etc.  Something along those
lines.  But I'd actually be surprised if *any* implementation
allocated extra space in an Employee_Data record to hold the bounds of
each field.

                                             -- Adam

Re: Null Range in Unconstrasined Array

[Stephen Leake]

Adam Beneschan <adam@irvine.com> writes:

> To elaborate on this a bit further: Suppose you define a record type
> for reading a file with Ada.Direct_IO, that looks something like this:
>
>   type Employee_Data is record
>       Name     : String (1 .. 50);
>       Address1 : String (1 .. 40);
>       Address2 : String (1 .. 40);
>       City     : String (1 .. 30);
>       State    : String (1 .. 2);
>       ...
>   end record;
>
> (Reminds me of my COBOL programming days...)  Anyway, it would be very
> unexpected for the compiler to put two extra integers in the record
> for each of these strings, and it would mess up your file I/O.  

If you expect the layout of this record to match your file, you must
provide a representation clause.

> But you have to have the ability to pass any of those fields to a
> subprogram with a parameter type "String", and the bounds have to be
> passed to the subprogram somehow. I think it's most likely that the
> bounds will be passed separately, as Bob suggested, either by
> passing them in separate registers, creating a three-word temporary
> structure that contains the bounds and a pointer to the data and
> passing the address of that structure (with that structure
> disappearing after the subprogram returns), creating a two-word
> structure with the bounds and passing the address of that in a
> register, etc. Something along those lines. But I'd actually be
> surprised if *any* implementation allocated extra space in an
> Employee_Data record to hold the bounds of each field.

It _could_ depend on whether there's a pragma Pack, or a
representation clause, for the record. In the absence of such, I would
expect the compiler to treat these components the same way it treats
separate objects. Which means I would expect the bounds to be stored
with the object.

But that's just my expectations; compilers are free to do whatever they
want, as long as it meets the standard.

-- 
-- Stephe

Re: Null Range in Unconstrasined Array

[Robert A Duff]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Adam Beneschan <adam@irvine.com> writes:
>
>> To elaborate on this a bit further: Suppose you define a record type
>> for reading a file with Ada.Direct_IO, that looks something like this:
>>
>>   type Employee_Data is record
>>       Name     : String (1 .. 50);
>>       Address1 : String (1 .. 40);
>>       Address2 : String (1 .. 40);
>>       City     : String (1 .. 30);
>>       State    : String (1 .. 2);
>>       ...
>>   end record;
>>
>> (Reminds me of my COBOL programming days...)  Anyway, it would be very
>> unexpected for the compiler to put two extra integers in the record
>> for each of these strings, and it would mess up your file I/O.  
>
> If you expect the layout of this record to match your file, you must
> provide a representation clause.

Good idea.

> It _could_ depend on whether there's a pragma Pack, or a
> representation clause, for the record. In the absence of such, I would
> expect the compiler to treat these components the same way it treats
> separate objects.

Yes.

>...Which means I would expect the bounds to be stored
> with the object.

Most compilers, including GNAT, will not store the bounds with the
object (whether it's a component or a standalone object).
Think about an array of a million of those records:
you don't want 1,000,000 copies of the number 50 stored
at run time.  That number is known to the compiler, and can
be plugged in wherever needed (e.g. when you say
"for X in A(Y).Name'Range loop", the compiler knows that's
just "for X in 1..50 loop".

> But that's just my expectations; compilers are free to do whatever they
> want, as long as it meets the standard.

Right.

- Bob

Re: Null Range in Unconstrasined Array

[sjw]

On Sep 9, 9:35 am, Stephen Leake <stephen_le...@stephe-leake.org>
wrote:
> Adam Beneschan <a...@irvine.com> writes:
> > To elaborate on this a bit further: Suppose you define a record type
> > for reading a file with Ada.Direct_IO, that looks something like this:
>
> >   type Employee_Data is record
> >       Name     : String (1 .. 50);
> >       Address1 : String (1 .. 40);
> >       Address2 : String (1 .. 40);
> >       City     : String (1 .. 30);
> >       State    : String (1 .. 2);
> >       ...
> >   end record;

> It _could_ depend on whether there's a pragma Pack, or a
> representation clause, for the record. In the absence of such, I would
> expect the compiler to treat these components the same way it treats
> separate objects. Which means I would expect the bounds to be stored
> with the object.

After leaving out the ..., GNAT allocates 162 bytes for this record
(no dope bytes). Also, if you stream it, it takes just 162 bytes on
the stream.

Re: Null Range in Unconstrasined Array

[Stephen Leake]

sjw <simon.j.wright@mac.com> writes:

> On Sep 9, 9:35�am, Stephen Leake <stephen_le...@stephe-leake.org>
> wrote:
>> Adam Beneschan <a...@irvine.com> writes:
>> > To elaborate on this a bit further: Suppose you define a record type
>> > for reading a file with Ada.Direct_IO, that looks something like this:
>>
>> > � type Employee_Data is record
>> > � � � Name � � : String (1 .. 50);
>> > � � � Address1 : String (1 .. 40);
>> > � � � Address2 : String (1 .. 40);
>> > � � � City � � : String (1 .. 30);
>> > � � � State � �: String (1 .. 2);
>> > � � � ...
>> > � end record;
>
>> It _could_ depend on whether there's a pragma Pack, or a
>> representation clause, for the record. In the absence of such, I would
>> expect the compiler to treat these components the same way it treats
>> separate objects. Which means I would expect the bounds to be stored
>> with the object.
>
> After leaving out the ..., GNAT allocates 162 bytes for this record
> (no dope bytes). 

Ok, my expectations are duly updated :).

> Also, if you stream it, it takes just 162 bytes on the stream.

That's not surprising: LRM 13.13.2 says:

    3
    S'Write

         S'Write denotes a procedure with the following specification:

    4/2
              procedure S'Write(
                 Stream : not null access Ada.Streams.Root_Stream_Type'Class;
                 Item : in T)

    5
         S'Write writes the value of Item to Stream.


The value clearly does not include the bounds.

-- 
-- Stephe