From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,45a9122ddf5fcf5 X-Google-Attributes: gid103376,public From: kst@thomsoft.com (Keith Thompson) Subject: Re: Valid Attribute and Unchecked Conversion Date: 1996/10/04 Message-ID: #1/1 X-Deja-AN: 187101858 sender: news@thomsoft.com (USENET News Admin @flash) x-nntp-posting-host: pulsar references: <1996Oct1.100608.1@eisner> organization: Thomson Software Products, San Diego, CA, USA newsgroups: comp.lang.ada originator: kst@pulsar Date: 1996-10-04T00:00:00+00:00 List-Id: In 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