Re: Valid Attribute and Unchecked Conversion

[kst@thomsoft.com (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