Constant array declarations are not causing a compilation error when not fully initialized.

Constant array declarations are not causing a compilation error when not fully initialized.

[Mark Doherty]

Why does the Ada95 LRM not gaurantee a compilation error for the
following, albeit does produce a CONTRAINT_ERROR.


procedure Test is

  type Enum is (A, B, C);

  -- the following don't produce compilation errors (just warning on
different
  -- versions of the compiler 
  Lookup_1 : constant array (Enum) of Integer := (A => 1);
  Lookup_2 : constant array (Enum) of Integer := (A => 1, B => 2);
  Lookup_3 : constant array (Enum) of Integer := (B => 1, C => 3);
  Lookup_4 : constant array (Enum) of Integer := (10, 12);

  -- the following does produce compilation error (as expected)
  Lookup_5 : constant array (Enum) of Integer := (A => 1,C => 2);

begin
    null;
end Test;

p.s. Different versions of the Rational compiler (but not all) issue a
warning that ... CONSTRAINT_ERROR will be raised...

Re: Constant array declarations are not causing a compilation error when not fully initialized.

[Tucker Taft]

Mark Doherty wrote:
> 
> Why does the Ada95 LRM not gaurantee a compilation error for the
> following, albeit does produce a CONTRAINT_ERROR.

This is similar to: "X : Positive := -1;"
This is legal at compile-time, but will result in
a constraint error at run-time.  Most compilers
are "friendly" enough to report cases where code
will unevitably raise a Constraint_Error, but by
the rules of the language, they are *not* allowed
to reject such code as being illegal.  

The reason the rules don't require such rejection is
that it is generally difficult to specify exactly
how sophisticated such inevitable-run-time-error detection
must be.  In fact, Ada 95 goes further than Ada 83 in
terms of specifying cases where inevitable-run-time-errors
must be detected, but it clearly can't go all the way,
as that would require the solution to the "halting" problem ;-).


> 
> procedure Test is
> 
>   type Enum is (A, B, C);
> 
>   -- the following don't produce compilation errors (just warning on
> different
>   -- versions of the compiler
>   Lookup_1 : constant array (Enum) of Integer := (A => 1);
>   Lookup_2 : constant array (Enum) of Integer := (A => 1, B => 2);
>   Lookup_3 : constant array (Enum) of Integer := (B => 1, C => 3);
>   Lookup_4 : constant array (Enum) of Integer := (10, 12);
> 
>   -- the following does produce compilation error (as expected)
>   Lookup_5 : constant array (Enum) of Integer := (A => 1,C => 2);
> 
> begin
>     null;
> end Test;
> 
> p.s. Different versions of the Rational compiler (but not all) issue a
> warning that ... CONSTRAINT_ERROR will be raised...

-- 
-Tucker Taft   stt@avercom.net   http://www.avercom.net
Chief Technology Officer, AverCom Corporation (A Titan Company) 
Bedford, MA  USA (AverCom was formerly the Commercial Division of AverStar:
http://www.averstar.com/~stt)

Re: Constant array declarations are not causing a compilation error when not fully initialized.

[tmoran]

>how sophisticated such inevitable-run-time-error detection
>must be.  In fact, Ada 95 goes further than Ada 83 in
>terms of specifying cases where inevitable-run-time-errors
>must be detected, but it clearly can't go all the way,
>as that would require the solution to the "halting" problem ;-).
  Today's PC's CPU is nearly 1,000x as fast as the original.  How much
of that typically goes into faster compilation (ie, bigger programs),
how much to more complex languages, and how much to increased
compile time analysis?

Re: Constant array declarations are not causing a compilation error when not fully initialized.

[Tucker Taft]

tmoran@acm.org wrote:
> 
> >how sophisticated such inevitable-run-time-error detection
> >must be.  In fact, Ada 95 goes further than Ada 83 in
> >terms of specifying cases where inevitable-run-time-errors
> >must be detected, but it clearly can't go all the way,
> >as that would require the solution to the "halting" problem ;-).
>   Today's PC's CPU is nearly 1,000x as fast as the original.  How much
> of that typically goes into faster compilation (ie, bigger programs),
> how much to more complex languages, and how much to increased
> compile time analysis?

It is true that more compile-time analysis could, and probably
should, be performed by modern compilers.  However, if you
are asking about what analysis is *required* by the standard,
that is severely limited by what we can require all implementors
to implement exactly the same way.  Almost all Ada compilers
go beyond the standard in terms of warnings they produce, but
trying to formally specify exactly under what conditions a
given warning is provided would be extremely complicated, even
for a single existing implementation.  The only real specification
might end up being the source code, which is clearly not something
you would want to standardize on.

-- 
-Tucker Taft   stt@avercom.net   http://www.avercom.net
Chief Technology Officer, AverCom Corporation (A Titan Company) 
Bedford, MA  USA (AverCom was formerly the Commercial Division of AverStar:
http://www.averstar.com/~stt)