Re: 'size attribute inheritance

[bobduff@world.std.com (Robert A Duff)]

In article <mheaney-ya023680001208971859210001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>Here's a related example, something that happened to a member of our
>development team just last week.

You're mixing two issues here.  The next example is about uninitialized
variables, whereas stuff after that talks about input from hardware and
so forth.  In Ada 83, these were similar, in that any resulting garbage
would cause execution to be erroneous.  In Ada 95, however, use of
uninit vars is *not* erroneous.  Many cases of interfacing to hardware
remain erroneous, in Ada 95.

The difference makes sense, to me.  Interfacing to the outside world can
be isolated in specific modules, and carefully checked, whereas an
uninitialized variable is something that might happen anywhere in the
program.

>...The code was something like this
>
>declare
>   type Atype is array (Itype) of T;
>   AO : Atype;
>
>   Index : Itype;  -- note that this doesn't have a default
>begin
>   if P then
>
>      Index := <a valid value>;
>      ... AO (Index)...
>
>   else
>
>      ... AO (Index);  -- oops!
>
>   end if;
>...
>end;

>The problem was that Index hadn't been initialized at that point at which
>it was used to dereference the array, so the application was touching
>memory that it wasn't supposed to, and so, for this compiler and operating
>system, the application dumped core.

This was correct behavior for Ada 83, but if it's an Ada 95 compiler, it
has a bug.  The indexing expression must either raise C_E or P_E or else
return some value.  It can't dump core.

>The developer assumed that a Constraint_Error would be raised, but as I
>pointed out in the previous post, this is never a safe, portable assumption
>to make.  The compiler can legally omit a range check, reasoning that since
>Index is an object of type Itype, and Itype is the array index subtype, no
>check is required, because Index has to be in the array's range.

No longer true in Ada 95.

>Robert may be thinking of GNAT, which I think always puts in a range check,
>no matter what (or at least more often than other compilers).  But you
>can't depend on this behavior.

GNAT eliminates range checks that it can prove won't fail.  (I don't
really know how smart it is about that.)  In order to prove that
properly, the initial value of a variable, or lack thereof, has to be
taken into account.  For "... A(I) ...", if I contains random stack
junk, the compiler cannot eliminate the check, since it cannot prove I
is in range.  (In Ada 83, it could eliminate the check, because all it
had to prove is "either I is in range, or uninitialized", since the
uninitialized case was erroneous.)

>My own lesson was learned the hard way on a VAX.  I was reading into an
>object of an enumeration type, and using that object in a case statement. 
>I would get ACCVIO (equivalent to a segmentation fault under UNIX) when I
>got a flakey value from the hardware, which could happen at startup, and
>when power was cycled.

Ah, but this is a completely different issue (in Ada 95).  I agree with
you that when doing I/O or otherwise interfacing to the outside world,
one must be very careful to avoid erroneousness.  And I agree that part
of that carefulness should be making certain interface variables exactly
fill up the space allotted -- no extra bits lying around to cause
trouble.

- Bob