Re: Null Range in Unconstrasined Array

[Stephen Leake <stephen_leake@stephe-leake.org>]

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