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,c9f437cff8842e X-Google-Attributes: gid103376,public From: Keith Thompson Subject: Re: Enumeration representation Date: 1999/09/11 Message-ID: #1/1 X-Deja-AN: 523907136 Sender: kst@king.cts.com References: <37D8E3BC.175DB72C@newtech.it> <7rcceh$anh$1@nnrp1.deja.com> X-Trace: nusku.cts.com 937089450 79754 198.68.168.21 (11 Sep 1999 22:37:30 GMT) Organization: CTS Network Services Newsgroups: comp.lang.ada X-Complaints-To: newsmaster@cts.com Date: 1999-09-11T00:00:00+00:00 List-Id: Robert Dewar writes: > In article , > Keith Thompson wrote: > If you try to read > > such a value from an external interface, it's very difficult > > to check that you've gotten a valid value without invoking > > erroneous execution (undefined behavior). > > No, it is quite easy, do an unchecked conversion of the value > into the enumeration variable, or just read the value in > directly with appropriate low level I/O, then do a 'Valid test. > > And Keith, before you go rummaging around legalise in the RM, > be sure to read the relevant AI, whose purpose is basically > to say, yes of course the above works, whatever the RM says :-) Ok, I think you're right. As I recall, a strict reading of the RM implies that the above obvious approach invokes erroneous execution, though a conforming implementation would have to be somewhat perverse to make it do anything other than the obvious. (I think you could avoid erroneousness by wraping the enumeration variable in a record.) Given the AI (whose status I haven't followed lately), such an implementation would have to be both perverse and non-conforming -- hopefully an unlikely combination. Do you happen to remember the AI number? I'm pretty sure it was based on a comment I submitted. I still think that enumeration representation clauses, as currently defined, are more trouble than they're worth. I personally spent a great deal of time implementing them in TeleSoft's old Ada compiler -- and never used them outside a test program. If the definition hadn't gone to quite so much trouble to make them (nearly) invisible, they might have been more useful -- for example, by providing predefined attributes to convert between an enumeration value and its internal representation. Even an attribute that gives an integer type guaranteed to be Unchecked_Conversion-compatible with a given enumeration type would have helped, in a ugly sort of way. (I'm assuming such a type has to be of the same size and signedness as the (internal representation of the) enumeration type. Unless the semantics of Unchecked_Conversion between discrete types of different sizes are well-defined -- I've never been quite clear on that point.) -- Keith Thompson (The_Other_Keith) kst@cts.com San Diego Supercomputer Center <*> "Oh my gosh! You are SO ahead of your time!" -- anon.