Missing Index Value in Array Aggregate

Missing Index Value in Array Aggregate

[Charles H. Sampson]

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

               Charlie

Re: Missing Index Value in Array Aggregate

[Adam Beneschan]

On Sep 26, 6:21 am, csamp...@inetworld.net (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

Re: Missing Index Value in Array Aggregate

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message
news:1190822071.488118.316450@y42g2000hsy.googlegroups.com...
...
> 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);

To expand on this a bit, in Ada 95, array bounds "slide" on assignment -
only the length of the array matters. So the bounds given in the aggregate
are not necessarily meaningful. The assignment

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

is legal and does not raise Constraint_Error. Thus the number of cases where
you could tell statically that the aggregate is wrong is fairly few. There
are some, though; if the index values aren't continguous, the aggregate is
illegal:

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

And, as Adam points out, I'm not aware of any Ada compiler that doesn't put
out a warning when it knows an exception is going to be raised. Don't turn
off (or ignore) all warnings!

                                Randy.

Re: Missing Index Value in Array Aggregate

[Charles H. Sampson]

     Thanks to both of you for clarifying this.  For some
reason, I tend to forget sliding when thinking about
arrays in the abstract, although I use it quite often.
 
     I should have given more detail of the context.
Although it's not relevant now, here it is: The aggregate
was the initial value of a constant array object, the type
of that object being an anonymous array type whose index
is a constrained enumeration type.  My compiler did give
me the (proper) warning of a constraint error at run time.
Unfortunately, the warning was overlooked because the
compiler tends to put out a bunch of warnings of much
less value.
 
     My characterization of Ada as trying to "do... as much
as possible at compile-time" was off base.  While you do
get a lot more information from an Ada compiler than from
those for most other languages, I agree that Ada's
consistency, it's very small number of special cases,
is much more important.
 
     So, while the case I asked about was surprising at
first glance, I think the rationale behind it is fine.

               Charlie

-- 
     For an email response, insert "0824" between the 'c' and 's'.

Re: Missing Index Value in Array Aggregate

[Stephen Leake]

csampson@inetworld.net (Charles H. Sampson) writes:

>      I should have given more detail of the context.
> Although it's not relevant now, here it is: The aggregate
> was the initial value of a constant array object, the type
> of that object being an anonymous array type whose index
> is a constrained enumeration type.  My compiler did give
> me the (proper) warning of a constraint error at run time.
> Unfortunately, the warning was overlooked because the
> compiler tends to put out a bunch of warnings of much
> less value.

What compiler?

With GNAT, I have a policy to eliminate _all_ warnings by fixing the
source code. Same with Gnu C, when I'm forced to use that.

Doing so fixes bugs.

Sometimes I have to resort to a compiler switch to suppress a
warning, but very rarely.

-- 
-- Stephe

Re: Missing Index Value in Array Aggregate

[Ludovic Brenta]

Stephen Leake wrote:
> With GNAT, I have a policy to eliminate _all_ warnings by fixing the
> source code. Same with Gnu C, when I'm forced to use that.
>
> Doing so fixes bugs.
>
> Sometimes I have to resort to a compiler switch to suppress a
> warning, but very rarely.

Same here, and in addition I always compile with -gnatwa (enable all
optional warnings).

--
Ludovic Brenta.

Re: Missing Index Value in Array Aggregate

[Pascal Obry]

Ludovic Brenta a �crit :
> Same here, and in addition I always compile with -gnatwa (enable all
> optional warnings).

Same here and adding -gnatwe to fail when a single warning is issued by
the compiler.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Missing Index Value in Array Aggregate

[Maciej Sobczak]

On 28 Wrz, 18:21, Pascal Obry <pas...@obry.net> wrote:

> > Same here, and in addition I always compile with -gnatwa (enable all
> > optional warnings).
>
> Same here and adding -gnatwe to fail when a single warning is issued by
> the compiler.

Only these two? :-)

-fstack-check -gnata -gnatf -gnato -gnatv -gnatVa -gnatwa -gnatwd -
gnatwe -gnatwh -gnatwl -gnatwt -gnatwH -gnaty3aAbcdefhiklM120nprtux

Who can beat this? ;-)

Seriously - I find it helpful to use all these options together. The
initial impression is that the compiler is too picky, but after
fighting the code through all this it just reads like a prose.

--
Maciej Sobczak
http://www.msobczak.com/

Re: Missing Index Value in Array Aggregate

[roderick.chapman]

On Sep 28, 9:26 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> -fstack-check -gnata -gnatf -gnato -gnatv -gnatVa -gnatwa -gnatwd -
> gnatwe -gnatwh -gnatwl -gnatwt -gnatwH -gnaty3aAbcdefhiklM120nprtux

We regularly compile the SPARK tools with
 -gnato -gnatwa -gnatwe -gnatVa -fstack-check
here for internal testing purposes.  Unsurprisingly,
it works fine.

> Who can beat this? ;-)

The SPARK Toolset!

SPARK, just for starters, statically eliminates all
possibility of erroneous execution - I don't know of
any compiler that can do that... :-)

 - Rod, SPARK Team

Re: Missing Index Value in Array Aggregate

[Charles H. Sampson]

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

> csampson@inetworld.net (Charles H. Sampson) writes:
> 
> >      I should have given more detail of the context.
> > Although it's not relevant now, here it is: The aggregate
> > was the initial value of a constant array object, the type
> > of that object being an anonymous array type whose index
> > is a constrained enumeration type.  My compiler did give
> > me the (proper) warning of a constraint error at run time.
> > Unfortunately, the warning was overlooked because the
> > compiler tends to put out a bunch of warnings of much
> > less value.
> 
> What compiler?
> 
     I don't want to name names because I think it's a
decent compiler and I wouldn't want to scare off any poten-
tial user because of this minor issue.

> With GNAT, I have a policy to eliminate _all_ warnings by fixing the
> source code. Same with Gnu C, when I'm forced to use that.
> 
> Doing so fixes bugs.
> 
> Sometimes I have to resort to a compiler switch to suppress a
> warning, but very rarely.

     A good practice in general and I've been thinking
about it for our project.  Unfortunately, many of the
warnings are of things that might happen but won't, so it
would mean cluttering the code with something unnecessary,
usually with a small execution penalty, along with
comments about why such a strange thing is being done.
(Although I'm working on a real-time system, the execution
penalty is not an issue because we have more CPU power
than we know what to do with.)  Other warnings are things
we know about but can't change.  The most irritating
involves an array of 6-bit components, needed to interface
external hardware, which generates a warning that the code
is "less efficient" because of the component size.  Less
efficient than what, I've asked.  Code that doesn't work?

I don't think we have an ability to selectively suppress
warnings, although it might have been put in unnoticed by
me in one of the many upgrades in the 10+ years we've been
using this compiler.

               Charlie

-- 
     For an email response, insert "0824" between the 'c' and 's'.

Re: Missing Index Value in Array Aggregate

[Stephen Leake]

csampson@inetworld.net (Charles H. Sampson) writes:

> Stephen Leake <stephen_leake@stephe-leake.org> wrote:
>
>> With GNAT, I have a policy to eliminate _all_ warnings by fixing the
>> source code. Same with Gnu C, when I'm forced to use that.
>
>      A good practice in general and I've been thinking
> about it for our project.  Unfortunately, many of the
> warnings are of things that might happen but won't, so it
> would mean cluttering the code with something unnecessary,
> usually with a small execution penalty, along with
> comments about why such a strange thing is being done.

You should ask the compiler vendor to fix this, so it is easier to
eliminate the warnings in a reasonable way. They will never fix it if
they don't hear complaints. Make them earn their support fee!

Point out that they may lose a customer to AdaCore if they don't!

> The most irritating involves an array of 6-bit components, needed to
> interface external hardware, which generates a warning that the code
> is "less efficient" because of the component size. Less efficient
> than what, I've asked. Code that doesn't work?

Perfect example of a warning that should be suppressed.

> I don't think we have an ability to selectively suppress
> warnings, although it might have been put in unnoticed by
> me in one of the many upgrades in the 10+ years we've been
> using this compiler.

You can use 'pragma Suppress' / 'pragma Unsuppress' around the
offending code; that should be sufficient. See LRM 11.5.

Also ask the vendor if they have another way.

-- 
-- Stephe