Re: Missing Index Value in Array Aggregate

On Sep 26, 6:21 am, csamp...@xxxxxxxxxxxxx (Charles H. Sampson) wrote:
The compiler used in my work allowed an aggregate for
an array with an elaboration type index to omit one of the
index values. (There was no others choice.) As a result,
Constraint_Error was raised at library elaboration time,
which is a nasty bug to run down in this environment.

I was getting ready to file a bug report, certain
that this was a compile-time error rather than run-time,
when I decided to take a close look at that old LRM. I
was surprised to find that the legality rules of 4.4.3

Should be 4.3.3

appear to be designed to allow just that, particularly the
second clause of paragraph 18.

Does anyone know what the purpose of this is? I can
see that there's an occasional need for it, as in the case
of an aggregate for a formal parameter of an unconstrained
array type. It certainly seems to me that in the case of
an aggregate for a constrained array object, catching this
error at compile time in is line with Ada's concept of
doing as much as possible at compile time. Or am I wrong?
Are there other paragraphs that do require this to be
caught during compilation?

There can be nothing illegal about an aggregate such as

(2 => 1010, 3 => 2020, 4 => 3030)

when taken by itself. Any problems have to happen only when the
compiler knows what type is expected for the aggregate. When the
expected type is determined, the aggregate can resolve to any one-
dimensional array type whose index and element types are some integer
type; if the expected type is something else, then the aggregate is
illegal.

Note, though, that array *types* don't have bounds on their indexes.
An array subtype is an array type plus (possibly) a constraint, where
the constraint puts bounds on the indexes. Once the type of the above
aggregate is determined, the aggregate will have an (unnamed) subtype
of that type with a constraint of (2..4). Then, depending on what you
do with that aggregate, the subtype will be *converted* to some other
subtype. If you declare an object:

type int4 is array(1..4) of integer;
A : int4 := (2 => 1010, 3 => 2020, 4 => 3030);

the semantics involve a type conversion of the unnamed aggregate
subtype to "int4". The rules for type conversions are spelled out in
4.6. The result is that a Constraint_Error will be raised.

In general, type conversions raise Constraint_Error when the
constraint isn't satisfied; they don't make a program illegal. This
is consistent, because of course a compiler can't always catch every
case where a type conversion can cause a Constraint_Error:

type intx is array (I..J) of integer;
A : intx := (2 => 1010, 3 => 2020, 4 => 3030);

where I and J are, say, procedure parameters.

Ada 83 was consistent about this. In Ada 95, I believe that some
constraint violations can make a program illegal, when static
expressions are involved, but only if they occur in the *middle* of
evaluating a static expression (4.9(34)), not when a static expression
can be evaluated but is known to be outside the bounds of the subtype
it will be converted to.

In any event, though, when it comes to catching subtype constraint
violations, I don't think "doing as much as possible at compile time"
is part of the Ada philosophy, since it leads to inconsistencies, and
having clear and consistent rules is very important also. That's just
my guess at an explanation for why this isn't illegal.

Our compiler, by the way, would probably have caught the aggregate you
tried to use (depending on the exact construct). It would have
displayed a warning that an exception will be raised at runtime. I
just tried GNAT, and it also displays a warning at least in the case I
tried. Our compiler also has an option that will treat a program as
illegal if it encounters any such cases where an exception is known to
be raised, but then of course this isn't strictly Ada.

-- Adam

.

Relevant Pages

  • Re: Missing Index Value in Array Aggregate
    ... An array subtype is an array type plus a constraint, ... the constraint puts bounds on the indexes. ... aggregate is determined, the aggregate will have an subtype ...
    (comp.lang.ada)
  • Re: Idea for ECMA/C# Standard - compile time hash for performance
    ... I agree with you the chance of a compiler change is slim, ... and then delegating to the standard hash for fields accessed less frequently. ... or the array lookup which would require the ... > 64-bit architecture) for each enum value that doesn't map to anything. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Q: Checking the size of a non-allocated array?
    ... an actual argument is already invalid ... First note that you don't have an unallocated array in the subroutine. ... it is comparable to disassociated or undefined pointers. ... Obviously the compiler has ...
    (comp.lang.fortran)
  • Re: Windows array allocation problem
    ... array reference has to have a 64-bit index or array subscript triplet? ... to fit in one. ... That assumes, of course, that your compiler ... limits on just about anything. ...
    (comp.lang.fortran)
  • Re: Error handling library
    ... which lets the compiler catch out-of-range usage. ... and assuming that a higher int means "more dangerous error" ... with a comment warning that one is used as an index into the array ... languages while running (an array of languages, ...
    (comp.lang.c)