Re: 'size attribute inheritance

[mheaney@ni.net (Matthew Heaney)]

In article <dewar.871345653@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

>Matthew says
>
><<YOU SHOULD NEVER USE CONSTRAINED SUBTYPES TO TRANSMIT OR RECIEVE DATA
>ACROSS AN EXTERNAL INTERFACE.>>
>

Robert reponds:

>There is no possible justification for such a rule (in caps or otherwise)
>in my opinion. Sure you have to be careful to know what you are doing,
>but this rule is entirely unsupportable. What is important is to use
>appropriate representation clauses and pragmas. If this is done, the
>above rule is not helpful.

Matthew replies:

I stated this guideline under the assumption that your external device is
unreliable.  I have had many occasions when I got spurious I/O completion
(say, the power was cycled), and the resulting data at the address was
complete garbage.

If you trust your device (perhaps it's a UNIX-domain socket, or a VMS
mailbox), then you could put constraints on the data, knowing it could
never be out of range.  I don't recommend it, but you could.

However, Robert's statement that "there is no possible justification for
such a rule" is a bit strong.  I think it's downright scary to think that
an object of a constrained subtype can have a value outside its range. 
What is the behavior of the program if that object is used to dereference
an array, or used in a case statement?

Here's a related example, something that happened to a member of our
development team just last week.  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;

From time to time, the program was getting a core dump.  He carefully
traced the execution of the program, and it always dumped when it reached
the dereference of array object AO in the else part of the if statement.

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.

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.

In fact, this is the very reason programmers are admonished to write their
for loops by explicitly stating the array index subtype in the declaration
if the loop index, because that will turn range checks off inside the loop,
when dereferencing the array using the loop index.

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.

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.

Your mileage may vary, but I really, really recommend you err on the side
of safety here, and not read data from an external device into an object of
a contrained subtype.  Think of how many UNIX security breaches have been
caused by deliberately overflowing data into certain areas of memory.

Consider yourself fortunate that you get any indication that a value is
outside its constrained range.  But even then, if you're flying a plane
controlled by software that has an illegal value for an object, is a core
dump really want you'd want to happen?

Please be very, very careful with data from an external source.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271