Re: Don't we already have a 'Valid? (was Re: Unchecked_Conversion...)

Re: Don't we already have a 'Valid? (was Re: Unchecked_Conversion...)

[Mike Berman]

Apologies for following up my own posting, but I've already received
some e-mail on the topic and thought I'd clear up some ambiguities.

The prior discussion on unchecked_conversion has quite adequately
explained why the code I excerpted operates the way it does. The result
of the unchecked_conversion makes the program erroneous if it is not a
valid member of the target type.

The real question is why does the "type_mark" form of the "in" operator
exist? Most people use "in" solely for checking ranges within a scalar
type, but it is defined to operate on _any_ type. Since it can't be used
to check the results of unchecked_conversions, then why is it defined
for nonscalar types?

And, as the subject line suggests, why not use the already-defined
syntax for the "in" operator _instead_ of adding the 'Valid attribute?

-- 
Mike Berman
University of Maryland, Baltimore County     Fastrak Training, Inc.
berman@umbc.edu                              (301)924-0050
       The views represented in the above post are my own.

Re: Don't we already have a 'Valid? (was Re: Unchecked_Conversion...)

[cis.ohio-state.edu!news.sei.cmu.edu!magnesium.club.cc.cmu.edu!honeydew.sr]

In article <26q196INNl1t@umbc4.umbc.edu> berman@umbc.edu (Mike Berman) writes:

> . . .
>The real question is why does the "type_mark" form of the "in" operator
>exist? Most people use "in" solely for checking ranges within a scalar
>type, but it is defined to operate on _any_ type. Since it can't be used
>to check the results of unchecked_conversions, then why is it defined
>for nonscalar types?
>
>And, as the subject line suggests, why not use the already-defined
>syntax for the "in" operator _instead_ of adding the 'Valid attribute?

The purpose of the "in" operation with a (sub)type_mark is to check 
whether a value of a given type satisfies the constraints associated
with a given subtype.  For a composite type, that comes
down to checking the discriminants or array bounds of the value.
For a scalar type, it is a range check.  For an access type,
it is a discriminant or array bound check on the object designated
by the access value.  Of course if the composite type doesn't
have discriminants or array bounds, then the membership test
will always return True.

The basic problem with using the membership test
to check validity is that Ada 83 allows compilers to assume that
all variables are properly initialized with a value that belongs
to their subtype, since the execution is erroneous anyway if that
assumption is not true.   

In Ada 9X, these situations are considered bounded 
errors instead of erroneous, meaning that the compiler can't
allow the use of an uninitialized variable to result in a wild jump 
or wild store into memory, but the compiler is allowed to raise Program_Error
or give the "wrong" answer.  For example, Ada 9X would still allow
a membership test to return True in such a case, since
that doesn't necessarily lead to unbounded errors.

The purpose of the 'Valid attribute is to check the contents
of an object without "officially" reading its value.  As soon
as you read the value of an uninitialized (or improperly
initialized) variable, you are in an bounded error condition,
and a "friendly" compiler should raise Program_Error before
you even get to invoking the "in" operation (aka membership test).

On the other hand, using the 'Valid attribute on an uninitialied
object is not an error of any sort, and is guaranteed to either
return True or False (it will never raise Program_Error), based
on the actual contents of the object, rather than on what the
optimizer might have assumed about the contents of the object
based on some declaration.

By the way, we considered trying to use the membership
test for this purpose, but the fact that the left operand
of a membership test is a *value* means that it is a bit
"late" to be asking whether it is a "valid" value.  We want
encourage compilers to catch invalid values as soon as possible.

>Mike Berman
>University of Maryland, Baltimore County     Fastrak Training, Inc.

S. Tucker Taft   stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138

Re: Don't we already have a 'Valid? (was Re: Unchecked_Conversion...)

[Mark A Biggar]

In article <26q196INNl1t@umbc4.umbc.edu> berman@umbc.edu (Mike Berman) writes:
>The prior discussion on unchecked_conversion has quite adequately
>explained why the code I excerpted operates the way it does. The result
>of the unchecked_conversion makes the program erroneous if it is not a
>valid member of the target type.
>The real question is why does the "type_mark" form of the "in" operator
>exist? Most people use "in" solely for checking ranges within a scalar
>type, but it is defined to operate on _any_ type. Since it can't be used
>to check the results of unchecked_conversions, then why is it defined
>for nonscalar types?

Well in 9x, with tagged types it is useful for asking if a classwide
variable is of a given tagged type.

>And, as the subject line suggests, why not use the already-defined
>syntax for the "in" operator _instead_ of adding the 'Valid attribute?

The complier is allowed to optimize way an "in" operator, but is specifically
forbiden to touch a 'VALID, otherwise they should act the same.

--
Mark Biggar
mab@wdl.loral.com

Re: Don't we already have a 'Valid? (was Re: Unchecked_Conversion...)

[Robert I. Eachus]

In article <CD59oG.Mru@yktnews.watson.ibm.com> ncohen@watson.ibm.com (Norman H.
 Cohen) writes:

   > It seemes to me that the 9X RM actually needs a little more
   > tinkering to make it work...

   I follow Norm's logic, but I can't agree with the conclusion.  As
Norm reads the manual right now (and I agree) the following sequence
should either assign true to B or raise PROGRAM_ERROR:

    declare
      I: Integer := Signalling_NaN;
      B: Boolean := False;
      S: Short_Float; -- change as necessary for your implementation...
      function UC is new Unchecked_Conversion(From => Integer, To => Float);
    begin
      S := UC(I);
      B := Short_Float'VALID(S);
    end;

    changing the order to:

    declare...
    begin
      B := Short_Float'VALID(UC(I));
      S := UC(I);
    end;

    may change things but doesn't really help.  (In fact it is
technically slightly worse.  There can be cases where B is assigned
True AND PROGRAM_ERROR is then raised. But I can't imagine a real
instance of this program where the call to UC produced different
results.)

    What you really want to be able to say is:

    declare...
    begin
      B := Short_Float'VALID(I);
      S := UC(I);
    end;

    Which would test whether the bits of I are would be a valid value
of type short_float after the Unchecked_Conversion.  I'm not
recommending this feature be added to the language, I'm just pointing
out that it probably has a much lower (implementation and run-time)
cost than requiring that B never be stored in a floating point
register until its value is formally accessed.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Don't we already have a 'Valid? (was Re: Unchecked_Conversion...)

[Norman H. Cohen]

Some clarifications: 

1. Thanks to Ben Brosgol has pointed out to me (in private
   correspondence) that I muffed the syntax of the 'Valid attribute: 
   It's not subtype'Valid(object), but object'Valid.

2. The tinkering I claimed was necessary concerned an assertion in the
   ANNOTATED Ada 9X Reference Manual that it is a ramification of rules
   in the 9X Reference Manual itself that an unchecked conversion
   is erroneous if it produces an invalid value of the target type, i.e.,
   that the very act of performing the unchecked conversion can render
   all subsequent execution unpredictable, regardless of how that value
   is used.  I don't believe this is the intent of the Revision Team.
   My guess is that the assertion in the ANNOTATED Reference Manual is
   false, i.e., this unwanted property is NOT really a ramification of
   rules in the Reference Manual.  In this case the only needed tinkering
   would be with the annotations describing the proposed standard, not
   with the proposed standard itself.

3. Like Robert Eachus (if I understand his post correctly), I believe
   that the best solution would have been an attribute like

      target_subtype'Would_Be_Valid(source_object)

   indicating without performing the unchecked conversion of
   source_object to target_subtype whether the bits of source_object are
   a valid representation of a value of target_subtype.  This provides a
   convenient way for the programmer to validate untrustworthy data
   without ever constructing invalid values.  (I'm sure there is a better
   name, but Would_Be_Valid conveys my intent.)

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Don't we already have a 'Valid? (was Re: Unchecked_Conversion...)

[cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!howland.]

In article <CDAooM.nEt@yktnews.watson.ibm.com> ncohen@watson.ibm.com 
(Norman H. Cohen) writes:

> [deleted]
>   3. Like Robert Eachus (if I understand his post correctly), I believe
>      that the best solution would have been an attribute like
>
>         target_subtype'Would_Be_Valid(source_object)
>
>      indicating without performing the unchecked conversion of
>      source_object to target_subtype whether the bits of source_object are
>      a valid representation of a value of target_subtype.  This provides a
>      convenient way for the programmer to validate untrustworthy data
>      without ever constructing invalid values.  (I'm sure there is a better
>      name, but Would_Be_Valid conveys my intent.)

I agree, this would be preferable in cases where Unchecked_Conversion
is used.  'Valid would still be necessary, however, to test in cases
where invalid values may be produced by other means.  (Section 13.10.1
of the Ada 9X Draft Version 3.0 lists these cases; IMHO the most
important are input from a file and interfacing to another language.)

                                -- Adam

Re: Don't we already have a 'Valid? (was Re: Unchecked_Conversion...)

[Tucker Taft]

In article <CDAooM.nEt@yktnews.watson.ibm.com> ncohen@watson.ibm.com writes:
>Some clarifications: 

>3. Like Robert Eachus (if I understand his post correctly), I believe
>   that the best solution would have been an attribute like
>
>      target_subtype'Would_Be_Valid(source_object)
>
>   indicating without performing the unchecked conversion of
>   source_object to target_subtype whether the bits of source_object are
>   a valid representation of a value of target_subtype.  This provides a
>   convenient way for the programmer to validate untrustworthy data
>   without ever constructing invalid values.  (I'm sure there is a better
>   name, but Would_Be_Valid conveys my intent.)

There are a few reasons why we chose the object'Valid approach
rather than the above "attribute-function" approach (all nicely 
documented by Ben Brosgol in the Ada 9X Rationale document coming 
out imminently):

   1) The above proposal implies a function call, which takes a value,
      not an object, as a parameter, meaning that the source object must
      already have a valid value or else the implementation is
      allowed to raise Program_Error.  Furthermore, what is the
      formal type of the parameter to the "Would_Be_Valid" function?

   2) Unchecked_Conversion takes a source *sub*type and a target subtype
      as generic parameters.  That is critical because 
      the particular subtypes specified can affect the actual number of
      bits involved in the unchecked conversion.  By contrast,
      the attribute-function approach is given a value, which does
      not indicate unambiguously how many bits will be involved
      in the conversion (which matters when converting between
      bit arrays and scalars on a big-endian machine, for example).

   3) A common source of potentially invalid data is from input
      or unchecked conversion of a whole record.  It is much more
      convenient to check the fields of interest of a record with
      the object-attribute approach, rather than the attribute-function
      approach applied to slices of the source of the record.  E.g.:

         type Enum is (ABC, XYZ, ...);
         type Enum_Array is array(Positive range <>) of Enum;
         type Enum_Stack is record
             Length : Natural range 0..Max := 0;
             Data : Enum_Array(1..Max);
         end record;
         Stk : Enum_Stack;
      ...
         Read_Stack(Into => Stk);
         if not Stk.Length'Valid then
             Put_Length("Bogus Length");
             raise Data_Error;
         else
             for I in 1..Stk.Length loop
                 if not Stk.Data(I)'Valid then
                     Put_Line("Trouble in River City");
                     raise Data_Error;
                 end if;
             end loop;
         end if;
         -- Stk now checked out, relevant data is valid

An alternative to the attribute-function approach that would
almost work would be a generic "Checked_Conversion" function, which would
combine the conversion with a validity check.  However, since validity
is not unambiguously defined for composite types (because of examples
like the Stack above), Checked_Conversion would be limited to scalar
types, which would make it pretty inconvenient.

By the way, we believe we have fixed the wording problems in the
manual in the latest version, so that the Unchecked_Conversion is
not erroneous, even if the bits being converted do not correspond
to a valid value of the target subtype.

>Norman H. Cohen    ncohen@watson.ibm.com

S. Tucker Taft   stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138