Valid Attribute and Unchecked Conversion

Valid Attribute and Unchecked Conversion

[Matthew Heaney]

In article <qw6buemy9ea.fsf@gargantua.enst.fr>, Samuel Tardieu
<sam@ada.eu.org> wrote:

>I don't think that the Valid attribute has been put in the language to
>be used after an Unchecked_Conversion, but rather to be used after
>calls to imported subprograms and calls to Read attributes (data
>coming from a stream).

That's odd, because RM95, section 13.9.2 states that "The valid attribute
can be used to check the validity of data produced by unchecked
conversion,..."

Note 19 in that section (of the AARM) states that "invalid data" can be
created as "the result of unchecked conversion."

Note 20 states that since X'Valid is not considered a read of X, it is not
an error the check the validity of invalid data.

So it's legal to check (using the valid attribute) the value of a (scalar)
object with an invalid representation, right?

Given the following program:

   declare
      type T is range 1 .. 10;
      function To_T is new Unchecked_Conversion (Integer, T);
      O : constant T := To_T (0);
   begin
      if O'Valid then
         ...
   end;

I want to know if the program is correct.  Is it erroneous, yes or no?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: Valid Attribute and Unchecked Conversion

[Robert A Duff]

In article <mheaney-ya023180000110962027510001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>So it's legal to check (using the valid attribute) the value of a (scalar)
         ^^^^^ you me "not erroneous".
>object with an invalid representation, right?

Right.

>Given the following program:
>
>   declare
>      type T is range 1 .. 10;
>      function To_T is new Unchecked_Conversion (Integer, T);
>      O : constant T := To_T (0);

I can't read that clearly on my screen, but I assume the variable name
is the letter oh, and the expression is the number zero.  ;-)

>   begin
>      if O'Valid then
>         ...
>   end;
>
>I want to know if the program is correct.  Is it erroneous, yes or no?

This is essentially the same as the example in 13.9.1(12.d), which I
posted a couple of days ago.  It is erroneous, by 13.9.1(12).  This has
nothing to do with the 'Valid attribute -- the above program becomes
erroneous before it gets to the 'Valid.  What I mean is, it's not that
'Valid doesn't work.  It's that Unchecked_Conversion is explicitly
defined to be erroneous in the above case.

Note that the rules for I/O are somewhat different than for
unchecked_conversion, primarily because function results are different
from 'out' parameters.

- Bob

Re: Valid Attribute and Unchecked Conversion

[Robert I. Eachus]

In article <mheaney-ya023180000110962027510001@news.ni.net> mheaney@ni.net (Matthew Heaney) writes:

  > So it's legal to check (using the valid attribute) the value of a (scalar)
  > object with an invalid representation, right?

  Right, but...

  > Given the following program:

  >    declare
  >	 type T is range 1 .. 10;
  >	 function To_T is new Unchecked_Conversion (Integer, T);
  >	 O : constant T := To_T (0);
  >    begin
  >	 if O'Valid then
  >	    ...
  >    end;

  > I want to know if the program is correct.  Is it erroneous, yes or no?

   It is erroneous.  That is the point of this discussion change to:

     declare
         type T is range 1 .. 10;
         for T'SIZE use Integer'SIZE;
  	 function To_T is new Unchecked_Conversion (Integer, T'Base);
  	 O : constant T := To_T (0);
      begin
  	 if O'Valid then
  	    ...
      end;

    Now To_T returns a bit pattern that is legal for the type (T'Base),
and the constraint check occurs on the assignment.  You never get to
the call to O'Valid.

    Change to:

     declare
         type T is range 1 .. 10;
         for T'SIZE use Integer'SIZE;
  	 function To_T is new Unchecked_Conversion (Integer, T'Base);
  	 O : T;
      begin
        begin
          O := To_T (0);
        exception when others => null;
        end;

   	if O'Valid then
  	  ...
      end;

      ...and you still don't get what you want.  In this case the
O'Valid check may or may not succeed, depending on the initial junk in
that stack location.

      'Valid is very useful for validating fields of record objects.
But for scalars that may be invalid, you usually want to produce a
(potentially) invalid value of the base type then do a (constraint
checked) assignment.

 
--

					Robert I. Eachus

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

Re: Valid Attribute and Unchecked Conversion

[George Haddad]

Robert I. Eachus wrote:
>     Change to:
> 
>      declare
>          type T is range 1 .. 10;
>          for T'SIZE use Integer'SIZE;
>          function To_T is new Unchecked_Conversion (Integer, T'Base);
>          O : T;
>       begin
>         begin
>           O := To_T (0);
>         exception when others => null;
>         end;
> 
>         if O'Valid then
>           ...
>       end;
> 
>       ...and you still don't get what you want.  In this case the
> O'Valid check may or may not succeed, depending on the initial junk in
> that stack location.

   So, what about:

      declare
        type T is range 1 .. 10;
        function To_T is new Unchecked_Conversion (Integer, T);
        X : T;
      begin
        if To_T(0)'Valid then
           X := To_T(0);
           ...
      end;

   I realize that this involves calling the same function twice (which 
is probably not a problem given that the function is an instance of 
Unchecked_Conversion), but is the fragment above erroneous?
-- 
I found these opinions on my doorstep, would you please give them a good 
home?

Re: Valid Attribute and Unchecked Conversion

[Matthew Heaney]

In article <EACHUS.96Oct2161139@spectre.mitre.org>,
eachus@spectre.mitre.org (Robert I. Eachus) wrote:

>     declare
>         type T is range 1 .. 10;
>         for T'SIZE use Integer'SIZE;
>         function To_T is new Unchecked_Conversion (Integer, T'Base);
>         O : constant T := To_T (0);
>      begin
>         if O'Valid then
>            ...
>      end;
>
>Now To_T returns a bit pattern that is legal for the type (T'Base),
>and the constraint check occurs on the assignment.  You never get to
>the call to O'Valid.

Thank you!  That clears it up.  I didn't realize that a Constraint_Check
ever could ever occur upon assignment of a value returned by an
instantiation of Unchecked_Conversion.

But your method forces a Constraint_Check to occur by making the type of
object O a subtype of the type returned by the function.  (Technically,
makes the function return a supertype of O's type.  Did I get that right?)

Very nice!

Matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: Valid Attribute and Unchecked Conversion

[Franco Mazzanti]

Robert I. Eachus wrote:

>    It is erroneous.  That is the point of this discussion change to:
> 
>      declare
>          type T is range 1 .. 10;
>          for T'SIZE use Integer'SIZE;
>          function To_T is new Unchecked_Conversion (Integer, T'Base);
>          O : constant T := To_T (0);
>       begin
>          if O'Valid then
>             ...
>       end;
> 
>     Now To_T returns a bit pattern that is legal for the type (T'Base),
> and the constraint check occurs on the assignment.  You never get to
> the call to O'Valid.
> 

However, we must be very careful not to generalize this approach.
E.g.  in the following very similar case:

      declare
          type T1 is new Integer range 1 .. 10;
          type T2 is new Integer range 1 .. 10;
          for T2'SIZE use T1'SIZE;
          function To_T is new Unchecked_Conversion (T1, T2'Base);
          S1:T1;  -- maybe initialized with zero
          S2:T2;
       begin
          S2:= 1;
          ...
          S2:= To_T2(S1);
          ...
          if O'Valid then
             ...
       end;

if S1 is not initialized, and has an invalid value, the call of To_T2 is
still directly erroneous (because the unchecked conversion still tries to
return an invalid scalar value!). 

It seems, in fact, that it is a generic principle in the Reference
Manual that invalid objects can be created ONLY by a missing initialization.
Once initialized, an object can no-more become "invalid". It can become,
at best, abnormal, and just storing its value in an object is erroneous.

My impression is that the safest generic approach still requires the use of 
a "Checked_Scalar_Conversion" as shown inside the previous thread
(Re: Rules for Representation of Subtypes).

Franco Mazzanti

Re: Valid Attribute and Unchecked Conversion

[John Herro]

I could be wrong, but I thought that Unchecked_Conversion is erroneous in
_any_ case.  I heard that the first validated Ada compiler, Ada/Ed, took
advantage of that fact and generated code to raise Program_Error wherever
the program tried to make use of Unchecked_Conversion.

Is this true, and if so, has any of it changed with Ada 95 and the new
'Valid attribute?

Someone please enlighten me.

- John Herro
Software Innovations Technology
http://members.aol.com/AdaTutor
ftp://members.aol.com/AdaTutor

Re: Valid Attribute and Unchecked Conversion

[Matthew Heaney]

In article <DyqAKA.DJn@thomsoft.com>, kst@thomsoft.com (Keith Thompson) wrote:

>So, suppose I have a sparse enumeration type:
>
>    type Enum is (Ten, Twenty, Thirty);
>    for Enum use (10, 20, 30);
>    for Enum'Size use 8;
>
>and a corresponding integer type:
>
>    type Int_Type is range 0 .. 31;
>    for Int_Type'Size use 8;
>
>Given an arbitrary value of type Int_Type, is there any non-erroneous
>way to get the corresponding Enum value if there is one, or raise
>an exception if there isn't?  By "corresponding", I mean 10 => Ten,
>20 => Twenty, 30 => Thirty.  Creating a lookup table that duplicates
>the information in the enumeration representation clause doesn't count;
>consider that Enum might be a generic formal type.  The 'Val attribute
>won't work, since it uses the position number (0, 1, 2) rather than the
>internal representation (10, 20, 30).

The answer would appear to be, No, there is no way to automatically get Ada
to raise an exception.  You have to check for a correct value before
unchecked converting to type Enum:

   function To_Enum is new Unchecked_Conversion (Int_Type, Enum);

   I : Int_Type := ...;
   E : Enum;
begin
   case I is
      when 10 | 20 | 30 =>
         E := To_Enum (I);
      when others =>
         raise <your favorite error>;
   end case;
end;

You raise an interesting point, though: this solution is complicated by the
fact that the representation values of type Enum are sparse.  Had they been
contiguous, you could force Ada to raise Constraint_Error via type
qualification:

   type ET is (E1, E2, E3);
   for ET use (3, 4, 5);
   for ET'Size use 8;

   type IT is range 0 .. 31;
   for IT'Size use 8;

   function To_ET is new Unchecked_Conversion (IT, ET);
   subtype ET_Rep is IT range 3 .. 5;

   I : IT := ...; 
   E : ET;
begin
   E := To_ET (ET_Rep'(I));  -- will raise Constraint_Error if I not in 3 .. 5, 
                                            -- thus preventing erroneous
execution

Of course, you could always instantiate Unchecked_Conversion using
the subtype ET_Rep directly.

Type qualification is useful technique for doing a kind of assertion
checking, forcing Ada to raise Constraint_Error when a value doesn't
satisfy a range constraint "precondition."  It's much hipper than the
explicit tests you see all the time:

   if I not in ET_Rep then          -- why bother?
      raise <I is bad error>;     
   end if;                               

  <handle good value here>

Type qualification gives you this for free.

For a static subtype, qualification means you don't have to include all the
branches in a case statement:

   case ET_Rep'(I) is    -- will raise Constraint_Error if I not in 3 .. 5
      when ET_Rep =>    -- other values for I don't have to be handled
         E := To_ET (I);
   end case;

A similar technique is to use a subtype indication to enforce a precondition:

   I : IT range ET_Rep'Range := ...;

After the expression on the right hand side is evaluated, Ada will check to
make sure that it lies within the range of ET_Rep before making the
assignment, raising Constraint_Error if the "precondition" isn't satisfied.

A subtype indication is also a useful documentation tool:

   Max_Value : constant FT := ...;

   Value : constant FT := ...;

   Normalized_Value : constant FT range 0.0 .. 1.0 := Value / Max_Value;

I'm giving the reader information, namely, that a "normalized value" means
that it has the range 0.0 .. 1.0.  I can use Ada to document this rather
than resorting to a comment.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: Valid Attribute and Unchecked Conversion

[Robert A Duff]

In article <DyqAKA.DJn@thomsoft.com>, Keith Thompson <kst@thomsoft.com> wrote:
>Are sparse enumeration types are really used all that much in real life?

They shouldn't be, because, as you explained, they don't work.  Using
sparse enums is asking for erroneousness.

Well, it's not *quite* that bad: You can use a sparse enum for sending
data from Ada to the outside world (e.g. doing output, passing
parameters *to* an imported subprogram, unchecked converting *from* a
sparse enum, etc).  But the other direction doesn't always work, and
should be avoided, IMHO.

The whole feature causes an awful lot of complexity in compilers,
given that it's not very useful.  Sigh.

- Bob

Re: Valid Attribute and Unchecked Conversion

[Karl Cooper {46901}]

John Herro wrote:
> 
> I could be wrong, but I thought that Unchecked_Conversion is erroneous in
> _any_ case.  I heard that the first validated Ada compiler, Ada/Ed, took
> advantage of that fact and generated code to raise Program_Error wherever
> the program tried to make use of Unchecked_Conversion.
> 
> Is this true, and if so, has any of it changed with Ada 95 and the new
> 'Valid attribute?
> 
No, see the Ada83 reference manual 13.10, and the Ada95 reference
manual 13.9 and 13.9.1.  Unchecked_Conversion leads to erroneous
behavior in some cases, but not in others.  In my opinion, the
Ada95 reference manual is clearer when describing the safe uses
of Unchecked_Conversion.

What is true is that an implementation is permitted to place
restrictions on the use of Unchecked_Conversion.  These should
be documented in one of the Appendices which describes the
implementation-dependent things defined by the implementation,
of course.  Again, the Ada95 reference manual gives more insight
into what sort of restrictions might be expected, as well as what
support for Unchecked_Conversion is recommended to implementors.

Because of the additional detail provided in the Ada95 LRM about
the safe uses of Unchecked_Conversion, I would suspect that a
validation suite could be created which would cause the behavior
you describe (unconditional Program_Error for each call to
Unchecked_Conversion) to be a failure of the valildation.
-- 
Karl T. Cooper               
Senior Software Engineer
Raytheon Electronic Systems
ktc@swl.msd.ray.com           <intelligence with intelligibility>

Re: Valid Attribute and Unchecked Conversion

[Franco Mazzanti]

(Keith Thompson) wrote:
> 
> >So, suppose I have a sparse enumeration type:
> >
> >    type Enum is (Ten, Twenty, Thirty);
> >    for Enum use (10, 20, 30);
> >    for Enum'Size use 8;
> >
> >and a corresponding integer type:
> >
> >    type Int_Type is range 0 .. 31;
> >    for Int_Type'Size use 8;
> >
> >Given an arbitrary value of type Int_Type, is there any non-erroneous
> >way to get the corresponding Enum value if there is one, or raise
> >an exception if there isn't? 


Matthew Heaney wrote:
> 
> The answer would appear to be, No, there is no way to automatically get Ada
> to raise an exception. 

Instead I think that there is a non-erroneous way to get corresponding
Enum value, or raise an exception:
(sorry to repost here a fragment of code previously posted in a different
thread)
Just use the following "checked" conversion:

generic
   type Source(<>) is limited private;
   type Target is (<>);
function Checked_Scalar_Conversion (S:Source) return Target;

with Unchecked_Conversion;
function Checked_Scalar_Conversion (S : Source) return Target is
   type My_Rec is record
      Scalar : Target;
   end record;
   Tmp : My_Rec;
   My_Scalar: Target renames Tmp.Scalar;
   -- small trick: even if Tmp as a whole record becomes abnormal
   -- its scalar component can still be safely checked for validity
   -- without "using" the abnormal record object.

   function Unchecked_Cvt is new Unchecked_Conversion (Source, My_Rec);
begin
   if My_Rec'Size /= Source'Size or
        My_rec'Alignment /= Source'Alignment then
      raise Program_Error;
   end if;
   Tmp := Unchecked_Cvt (S);
   if My_Scalar'Valid then
      return My_Scalar;
   else
      raise Program_Error;
   end if;
end Checked_Scalar_Conversion;

Now you can instantiate the Checked conversion with your types:


function Cvt is new Checked_Scalar_Conversion (Int_Type, Enum);

and use it

   N: Enum;
   N := Cvt (10);   -- OK
   N := Cvt (20);   -- OK
   N := Cvt (30);   -- OK
   N := Cvt (25);   -- raises Program_Error


Franco Mazzanti
(mazzanti@iei.pi.cnr.it)

Re: Valid Attribute and Unchecked Conversion

[Robert Dewar]

In article <DyqAKA.DJn@thomsoft.com>, Keith Thompson <kst@thomsoft.com> wrote:
>Are sparse enumeration types are really used all that much in real life?



In our experience they are used very extensively. Furthermore, we found that
we had to add the additional complexity of makeing sure that arrays indexed
by such types were compact (rather than mapped sparsely), since a couple of
large customers required this support.

Robert Dewar
Ada Core Technologies

Re: Valid Attribute and Unchecked Conversion

[Keith Thompson]

In <Dynt6I.5D1@world.std.com> bobduff@world.std.com (Robert A Duff) writes:
[...]
> This is essentially the same as the example in 13.9.1(12.d), which I
> posted a couple of days ago.  It is erroneous, by 13.9.1(12).  This has
> nothing to do with the 'Valid attribute -- the above program becomes
> erroneous before it gets to the 'Valid.  What I mean is, it's not that
> 'Valid doesn't work.  It's that Unchecked_Conversion is explicitly
> defined to be erroneous in the above case.

RM95-13.9.1(12) says:

	A call to an imported function or an instance of
	Unchecked_Conversion is erroneous if the result
	is scalar, and the result object has an invalid
	representation.

(To answer someone else's question, applying 'Valid directly to the
result of the Unchecked_Conversion is still erroneous.  (Note that
function results are considered (constant) objects in Ada 95, unlike in
Ada 83 where they're just values; one ramification is that you can now
rename a function result.  (But I digress.)))

The following paragraph in the AARM, 13.0.1(12.a), says:

        Ramification:  In a typical implementation, every
        bit pattern that fits in an object of an integer
        subtype will represent a value of the type, if not of
        the subtype.  However, for an enumeration or floating
        point type, there are typically bit patterns that do
        not represent any value of the type.  In such cases,
        the implementation ought to define the semantics of
        operations on the invalid representations in the
        obvious manner (assuming the bounded error is not
        detected):  a given representation should be equal
        to itself, a representation that is in between
        the internal codes of two enumeration literals
        should behave accordingly when passed to comparison
        operators and membership tests, etc.  We considered
        requiring such sensible behavior, but it resulted in
        too much arcane verbiage, and since implementations
        have little incentive to behave irrationally, such
        verbiage is not important to have.

Note that this annotation is *not* part of the standard.

So, suppose I have a sparse enumeration type:

    type Enum is (Ten, Twenty, Thirty);
    for Enum use (10, 20, 30);
    for Enum'Size use 8;

and a corresponding integer type:

    type Int_Type is range 0 .. 31;
    for Int_Type'Size use 8;

Given an arbitrary value of type Int_Type, is there any non-erroneous
way to get the corresponding Enum value if there is one, or raise
an exception if there isn't?  By "corresponding", I mean 10 => Ten,
20 => Twenty, 30 => Thirty.  Creating a lookup table that duplicates
the information in the enumeration representation clause doesn't count;
consider that Enum might be a generic formal type.  The 'Val attribute
won't work, since it uses the position number (0, 1, 2) rather than the
internal representation (10, 20, 30).

I'm beginning to think the "arcane verbiage" might have been worth it.

Are sparse enumeration types are really used all that much in real life?
My own interest is based, not on any actual usage, but on the gray hairs
I earned a few years ago while implementing them.

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
FIJAGDWOL

Re: Valid Attribute and Unchecked Conversion

[Robert Dewar]

John Herror said

"I could be wrong, but I thought that Unchecked_Conversion is erroneous in
_any_ case.  I heard that the first validated Ada compiler, Ada/Ed, took
advantage of that fact and generated code to raise Program_Error wherever
the program tried to make use of Unchecked_Conversion."

This is completely wrong. In both Ada 83 and Ada 95, there is nothing
erroneous about unchecked conversion unless an invalid result is 
produced. The wording from the Ada 83 RM for section 13.10.2 mentions
erroneousness only in one place:

"Whenever unchecked conversions are used, it is the programmers
responsibility to ensure that these conversions maintain the properties
that are guaranteed by the language for objects of the target type.
Programs that violate these properties by means of unchecked conversions
are erroneous."

The ACVC 1.11 suite contains a number of uses of unchecked conversion
that are required to work on all compilers and are not only NOT erroneous,
but are not even implementation dependent.

Now it is certainly the case that UC is implementation dependent, and an
implementation is allowed to place restrictions. In the case of Ada/Ed,
which is what you referred to, unchecked conversion made no sense in the
virtual machine used for the implementation, so all UC's were rejected.
Later on, Ada/Ed did implement many UC's, including those required by
the ACVC suite.

Never use the word erroneous casually, it is not a blanket term meaning
{undefined, implementation defined, wrong, illegal, inadvisable etc ..}
Only a few things in Ada 83 or Ada 95 are erroneous (fewer in Ada 95), and
the RM is very careful to document exactly what is and what is not
erroneous, so don't go by "I thought" here, read the RM carefully!

Note that in Ada 95, more uses of unchecked conversion are non-erroneous,
since a program can generate an abnormal value using UC, and then stay
non-erroneous as long as only 'Valid is used to query the result. 

Indeed the Ada 95 section on unchecked conversion (section 13.9) does not
mention the word erroneous at all, so an unchecked conversoin BY ITS SELF
never makes a program execution erroneous in Ada 95.

Re: Valid Attribute and Unchecked Conversion

[Keith Thompson]

In <dewar.844516953@schonberg> dewar@schonberg.cs.nyu.edu (Robert Dewar) writes:
[...]
> Indeed the Ada 95 section on unchecked conversion (section 13.9) does not
> mention the word erroneous at all, so an unchecked conversoin BY ITS SELF
> never makes a program execution erroneous in Ada 95.

But RM95-13.9.1(12) says:
	A call to an imported function or an instance of
	Unchecked_Conversion is erroneous if the result
	is scalar, and the result object has an invalid
	representation.

Probably that paragraph should have been in 13.9 rather than 13.9.1.

Note that there are several paragraphs after this in the AARM encouraging
implementations to behave sensibly:

	[...] We considered requiring such sensible behavior,
	but it resulted in too much arcane verbiage, and
	since implementations have little incentive to behave
	irrationally, such verbiage is not important to have.

So implementations are encouraged to implement sensibly something that
users are encouraged to avoid.

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
FIJAGDWOL

Re: Valid Attribute and Unchecked Conversion

[Keith Thompson]

In <Dyr7Dt.HqL@world.std.com> bobduff@world.std.com (Robert A Duff) writes:
[...]
> They shouldn't be, because, as you explained, they don't work.  Using
> sparse enums is asking for erroneousness.
[...]
> The whole feature causes an awful lot of complexity in compilers,
> given that it's not very useful.  Sigh.

Especially since it wouldn't have been difficult to make them useful.

The root of the problem, I think, is Ada 83's emphasis (not entirely
successful) on guaranteeing that representation clauses affect only
representation, not semantics.  In the case of enumeration types, this
was carried just a little too far, IMHO.

For example, the language could have defined two additional attributes,
analagous to 'Pos and 'Val, but operating on the internal representation
of an enumeration type.  If the argument is an invalid representation,
simply raise Constraint_Error.  GNAT provides half of this with its
'Enum_Rep attribute.

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
FIJAGDWOL

Re: Valid Attribute and Unchecked Conversion

[Robert Dewar]

Keith says

"For example, the language could have defined two additional attributes,
analagous to 'Pos and 'Val, but operating on the internal representation
of an enumeration type.  If the argument is an invalid representation,
simply raise Constraint_Error.  GNAT provides half of this with its
'Enum_Rep attribute."


The intention in Ada 95 is that both operations are achievbable using
unchecked conversion. It is a bug in the RM if this is not the case.

However, in practice, of coruse this works, no matter what it says in
the RM, so this point can be left moot without having any pragmatic 
effect.

Re: Valid Attribute and Unchecked Conversion

[Robert Dewar]

iKeith says

"        A call to an imported function or an instance of
        Unchecked_Conversion is erroneous if the result
        is scalar, and the result object has an invalid
        representation.

(To answer someone else's question, applying 'Valid directly to the
result of the Unchecked_Conversion is still erroneous.  (Note that
function results are considered (constant) objects in Ada 95, unlike in
Ada 83 where they're just values; one ramification is that you can now
rename a function result.  (But I digress.)))"


Keith is right, this is in the RM, but I think the RM is definitely wrong
here. I take part of the blame, I simply did not notice this particular
mistake. Obviously for scalar types, unchecked conversion (where the sizes
are the same) should not result in erroneous behavior, and a subsequent
call to 'Valid should also be non-erroneous.

I simply missed this because it is in the wrong section (not under UC).
Anyway, certainly GNAT behaves in a sensible manner here, and hopefully
all other Ada 95 compilers will too, so this mistake should have only
very limited impact.

Re: Valid Attribute and Unchecked Conversion

[Mark A Biggar]

In article <32550731.167EB0E7@swl.msd.ray.com> Karl Cooper {46901} <ktc@swl.msd.ray.com> writes:
>John Herro wrote:
>> I could be wrong, but I thought that Unchecked_Conversion is erroneous in
>> _any_ case.  I heard that the first validated Ada compiler, Ada/Ed, took
>> advantage of that fact and generated code to raise Program_Error wherever
>> the program tried to make use of Unchecked_Conversion.
>> Is this true, and if so, has any of it changed with Ada 95 and the new
>> 'Valid attribute?
>No, see the Ada83 reference manual 13.10, and the Ada95 reference
>manual 13.9 and 13.9.1.  Unchecked_Conversion leads to erroneous
>behavior in some cases, but not in others.  In my opinion, the
>Ada95 reference manual is clearer when describing the safe uses
>of Unchecked_Conversion.

Why was the Unchecked_Conversion of an invalid scalar made erroneous in LM 95 
instead of a bounded error like the coresponding uninitialized variable case?

--
Mark Biggar
mab@wdl.lmco.com

Re: Valid Attribute and Unchecked Conversion

[Ken Garlington]

Robert A Duff wrote:
> 
> In article <DyqAKA.DJn@thomsoft.com>, Keith Thompson <kst@thomsoft.com> wrote:
> >Are sparse enumeration types are really used all that much in real life?
> 
> They shouldn't be, because, as you explained, they don't work.  Using
> sparse enums is asking for erroneousness.
> 
> Well, it's not *quite* that bad: You can use a sparse enum for sending
> data from Ada to the outside world (e.g. doing output, passing
> parameters *to* an imported subprogram, unchecked converting *from* a
> sparse enum, etc).  But the other direction doesn't always work, and
> should be avoided, IMHO.

Or, you can do an unchecked conversion to a record with a single
component of the sparse enum type, right?

> The whole feature causes an awful lot of complexity in compilers,
> given that it's not very useful.  Sigh.
> 
> - Bob

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: Valid Attribute and Unchecked Conversion

[Kenneth Almquist]

kst@thomsoft.com (Keith Thompson) writes:
> RM95-13.9.1(12) says:
>
>	 A call to an imported function or an instance of
>	 Unchecked_Conversion is erroneous if the result
>	 is scalar, and the result object has an invalid
>	 representation.
[snip]
> So, suppose I have a sparse enumeration type:
>
>     type Enum is (Ten, Twenty, Thirty);
>     for Enum use (10, 20, 30);
>     for Enum'Size use 8;
>
> and a corresponding integer type:
>
>     type Int_Type is range 0 .. 31;
>     for Int_Type'Size use 8;
>
> Given an arbitrary value of type Int_Type, is there any non-erroneous
> way to get the corresponding Enum value if there is one, or raise
> an exception if there isn't?  By "corresponding", I mean 10 => Ten,
> 20 => Twenty, 30 => Thirty.

Do an unchecked conversion to a nonscalar type.

-- Convert Int_Type to Enum, raising constraint error if the result is
-- invalid.
function To_Enum(I : Int_Type) return Enum is
    type Wrapped_Enum is record
        Value : Enum;
    end record;
    for Wrapped_Enum'size use Enum'size;

    function To_Wrapped_Enum is new
        Ada.Unchecked_Conversion(Int_Type, Wrapped_Enum);
 
    W : Wrapped_Enum;
begin
    W := To_Wrapped_Enum(I);
    if W.Value'valid then
        return W.Value;
    else
        raise Constraint_Error;
    end if;
end To_Enum;

Re: Valid Attribute and Unchecked Conversion

[Robert Dewar]

Note that in practice, of course unchecked conversion followed by 'Valid
will work fine for the case of enumeration types with holes. This was
specifically intended as far as I am concerned, and the fact that the
final wordking of the RM contradicts this is a mistake that should be
fixed.

Re: Valid Attribute and Unchecked Conversion

[Alan Brain]

Robert A Duff wrote:
> 
> In article <DyqAKA.DJn@thomsoft.com>, Keith Thompson <kst@thomsoft.com> wrote:
> >Are sparse enumeration types are really used all that much in real life?
> 
> They shouldn't be, because, as you explained, they don't work.  Using
> sparse enums is asking for erroneousness.
> 
> Well, it's not *quite* that bad: You can use a sparse enum for sending
> data from Ada to the outside world (e.g. doing output, passing
> parameters *to* an imported subprogram, unchecked converting *from* a
> sparse enum, etc).  But the other direction doesn't always work, and
> should be avoided, IMHO.

Beg to differ; many systems send 0001, 0010, 0100, 1000 for the 4
different valid states, etc. You often get it coming and going in real
time apps. Even some disc controllers.
So you use a base type without representation (internally), and convert
to a represented derived type for output, and from a (maybe different)
represented derived type for input.

----------------------      <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
---------------------- o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling Maerklin Wagons, in 1/220 Scale

Re: Valid Attribute and Unchecked Conversion

[Robert Dewar]

Mark says

"Why was the Unchecked_Conversion of an invalid scalar made erroneous in LM 95
instead of a bounded error like the coresponding uninitialized variable case?"

For discrete types, I think this is an excellent question and cannot think of
any reasonable response.

For floating-point, you might have trouble with signalling NaN's, though
this could certainly be handled too.

Re: Valid Attribute and Unchecked Conversion

[Keith Thompson]

In <dewar.844696412@schonberg> dewar@schonberg.cs.nyu.edu (Robert Dewar) writes:
> Keith says
> 
> "For example, the language could have defined two additional attributes,
> analagous to 'Pos and 'Val, but operating on the internal representation
> of an enumeration type.  If the argument is an invalid representation,
> simply raise Constraint_Error.  GNAT provides half of this with its
> 'Enum_Rep attribute."
> 
> The intention in Ada 95 is that both operations are achievbable using
> unchecked conversion. It is a bug in the RM if this is not the case.

Ok, but unchecked conversion to what?  Since you can't get at the
underlying representation values as static expressions, there's no
portable way (that I know of) to declare an integer type of the same
size as an arbitrary enumeration type.  If I could write

    type Int_Type is range Enum_Type'Blorch(Enum_Type'First) ..
                           Enum_Type'Blorch(Enum_Type'Last);

(where 'Blorch is the non-existent attribute that returns the internal
code for an enumeration value), I could safely do unchecked conversions
between Int_Type and Enum_Type (if I ignore 13.9.1(12)).

Something like this is *probably* close enough:

    type Enum_Type is (...);
    for Enum_Type use (...);
    type Int_Type is range 0 .. 2**Enum_Type'Size-1;
    -- OR type Int_Type is mod 2**Enum_Type'Size;
    for Int_Type'Size use Enum_Type'Size; -- superfluous?
    function To_Int  is new Ada.Unchecked_Conversion(Enum_Type, Int_Type);
    function To_Enum is new Ada.Unchecked_Conversion(Int_Type, Enum_Type);

but it won't quite work if some of the enumeration codes are negative.

> However, in practice, of coruse this works, no matter what it says in
> the RM, so this point can be left moot without having any pragmatic 
> effect.

Moot in both senses of the word!  8-)}

I don't agree that there's no pragmatic effect.  The effect is not on
implementers, but on users.  Even if all implementations happen to behave
"sensibly" in this area, a careful user trying to write portable code
will avoid anything that the RM says is erroneous.

I think we need a binding interpretatin saying something like "When we
said 'erroneous' in 13.9.1(12), we were only kidding.  Yeah, there's
the ticket!"  8-)}  8-)}

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
FIJAGDWOL

Re: Valid Attribute and Unchecked Conversion

[Keith Thompson]

In <dewar.844696010@schonberg> dewar@schonberg.cs.nyu.edu (Robert Dewar) writes:
> Note that in practice, of course unchecked conversion followed by 'Valid
> will work fine for the case of enumeration types with holes. This was
> specifically intended as far as I am concerned, and the fact that the
> final wordking of the RM contradicts this is a mistake that should be
> fixed.

I've sent a message to this effect to ada-comment.  Maybe something will
actually happen.

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
FIJAGDWOL

Re: Valid Attribute and Unchecked Conversion

[Ken Garlington]

Robert Dewar wrote:
> 
> Keith is right, this is in the RM, but I think the RM is definitely wrong
> here. I take part of the blame, I simply did not notice this particular
> mistake. Obviously for scalar types, unchecked conversion (where the sizes
> are the same) should not result in erroneous behavior, and a subsequent
> call to 'Valid should also be non-erroneous.
> 
> I simply missed this because it is in the wrong section (not under UC).
> Anyway, certainly GNAT behaves in a sensible manner here, and hopefully
> all other Ada 95 compilers will too, so this mistake should have only
> very limited impact.

Can't we go a little further, and write an AI (similar to the Ada 83 AI on
unchecked conversion between scalars of the same size) to formally document
what should happen? It's good that the AARM says "act sensibly," but wouldn't
an AI be better?


-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: Valid Attribute and Unchecked Conversion

[Norman H. Cohen]

Concerning sparse enumeration types, Robert Dewar wrote:

>                                                   Furthermore, we found that
> we had to add the additional complexity of makeing sure that arrays indexed
> by such types were compact (rather than mapped sparsely), since a couple of
> large customers required this support.

But the work necessary to do this (mapping sparse encodings to a
contiguous set of values that can be used for array indexing) is already
necessary anyway to implement the 'Pos attribute.  

The Ada-83 RM contained a note (RM83-13.3(6)) warning that operations
such as 'Succ, 'Pred, 'Pos, and array indexing are likely to be less
efficient for sparse enumeration types than for ordinary ones.  The
warning is gone from the corresponding note in the Ada-95 RM
(RM95-14.4(11)), but surely the expectation of slower operations is
still there.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: Valid Attribute and Unchecked Conversion

[Robert Dewar]

"Can't we go a little further, and write an AI (similar to the Ada 83 AI on
unchecked conversion between scalars of the same size) to formally document
what should happen? It's good that the AARM says "act sensibly," but wouldn't
an AI be better?"

Well the first step is for someone to write a question and send it to
the appopriate email address (see Ada 95 RM). This will usually result
in an AI prepared by Bob Duff, although he will be happy to have help!

But this is not an easy AI to write. In particular, I suggest restricting
it to discrete types rather than scalar types, since floating-point types
are contentious because of signalling Nan's.

Also, be sure to think in terms of conversion between scalar *types* and
not scalar *objects*, since this is what UC is about. I am not quite
sure what the abbreviation scalars means above, but it smacks of scalar
object to me!

Re: Valid Attribute and Unchecked Conversion

[Robert Dewar]

iNorman Cohen says

"But the work necessary to do this (mapping sparse encodings to a
contiguous set of values that can be used for array indexing) is already
necessary anyway to implement the 'Pos attribute."



My goodness, that's perhaps 10% of the effort involved, that's the easy
part. If you want to investigate this statement further, feel free to
examine the GNAT sources. Have a look at exp_pakd.adb where most, but 
certainly not all the work is done. Luckly in GNAT we could piggyback off
the packed array stuff, which was already done in the front end (it might
be better to do it in the backend, but that's for the future, and luckily
for this particular issue, was not done yet!)

Yes, conceptually, the only issue is the mapping, but the problem is that
you have a situation where the conceptual type and the implementation
type are different (the conceptual type is indexed by the enumeration type,
the actual type by the representation of the enumeration type, for us these
are two separate types). As always, it is the implementation details, not
the algorithms that are the hard work!

Re: Valid Attribute and Unchecked Conversion

[Keith Thompson]

In <dewar.845050338@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> "Can't we go a little further, and write an AI (similar to the Ada 83 AI on
> unchecked conversion between scalars of the same size) to formally document
> what should happen? It's good that the AARM says "act sensibly," but wouldn't
> an AI be better?"
> 
> Well the first step is for someone to write a question and send it to
> the appopriate email address (see Ada 95 RM). This will usually result
> in an AI prepared by Bob Duff, although he will be happy to have help!

I've already done this.  See reference "96-5719.a Keith Thompson 96-10-7".

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
FIJAGDWOL

Re: Valid Attribute and Unchecked Conversion

[Robert A Duff]

In article <Dyvo0w.7Dr@thomsoft.com>, Keith Thompson <kst@thomsoft.com> wrote:
>But RM95-13.9.1(12) says:
>	A call to an imported function or an instance of
>	Unchecked_Conversion is erroneous if the result
>	is scalar, and the result object has an invalid
>	representation.
>
>Probably that paragraph should have been in 13.9 rather than 13.9.1.

True.

>Note that there are several paragraphs after this in the AARM encouraging
>implementations to behave sensibly:
>
>	[...] We considered requiring such sensible behavior,
>	but it resulted in too much arcane verbiage, and
>	since implementations have little incentive to behave
>	irrationally, such verbiage is not important to have.
>
>So implementations are encouraged to implement sensibly something that
>users are encouraged to avoid.

No, no.  The "sensible" comment in the AARM is *not* referring to the
paragraph about erroneousness of unchecked conversions.  It is referring
to the run-time behavior of "invalid" values, which can arise from many
things, but mainly uninitialized variables.  The intent is that (for
example):

    if X = Red and X /= Red then ...

should be True, despite the fact that X is not initialized (assuming the
compiler fails to catch the bounded error, and raise an exception).

This has nothing to do with the erroneousness defined in paragarph 12,
which would have been clearer if the AARM comment were after paragraph
11, rather than after paragraph 12.

- Bob

Re: Valid Attribute and Unchecked Conversion

[Ken Garlington]

Robert Dewar wrote:
> 
> "Can't we go a little further, and write an AI (similar to the Ada 83 AI on
> unchecked conversion between scalars of the same size) to formally document
> what should happen? It's good that the AARM says "act sensibly," but wouldn't
> an AI be better?"
> 
> Well the first step is for someone to write a question and send it to
> the appopriate email address (see Ada 95 RM). This will usually result
> in an AI prepared by Bob Duff, although he will be happy to have help!
> 
> But this is not an easy AI to write. In particular, I suggest restricting
> it to discrete types rather than scalar types, since floating-point types
> are contentious because of signalling Nan's.
> 
> Also, be sure to think in terms of conversion between scalar *types* and
> not scalar *objects*, since this is what UC is about. I am not quite
> sure what the abbreviation scalars means above, but it smacks of scalar
> object to me!

It does, indeed, smack of scalar object, for the reason that 'Valid is applied to
scalar objects, not scalar types.  I agree that UC is defined in terms of types,
but at some level it will have to be tied to the properties of scalar (more likely
discrete, as you said) objects, won't it? Otherwise, we may still have the
annoying proposition that:

   Y := Unchecked_Whatever(Z);
   if not Y'Valid then
     raise Whatever_Error;
   end if;

is not guaranteed to work for any given compiler, even assuming some reasonable 
restrictions on Y and Z (e.g., Y'Size >= Z'Size, both are discrete).

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com