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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!pasteur!ucbvax!AJPO.SEI.CMU.EDU!rracine
From: rracine@AJPO.SEI.CMU.EDU
Newsgroups: comp.lang.ada
Subject: Need for enumeration values
Message-ID: <8901231608.AA04345@ajpo.sei.cmu.edu>
Date: 23 Jan 89 16:08:40 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
List-Id: <comp.lang.ada>

The one time we would have liked the enumeration values in a type which
had a representation clause was in a communication subsystem.  The 
programmer thought she could use the attributes to change the type into
a numeric type for transmission.  Then, on the other side, she used
UNCHECKED_CONVERSION for changing it back.  Needless to say, it did not
work.  When I was consulted, it took a while for me to find the misuse
of the attribute.  All in all, it probably cost about one person-day to
solve.

To turn the question around, is there any need for the POS attribute to
work as it does?  Has anyone used it such that if the attribute gave the
actual value it would have been wrong?

By the way, I checked three Ada books to see what they say about the POS
attribute.  The LRM was the most clear (IF one looked in chapter 13).
The two other books (which are much more likely to be read than the LRM)
were vague enough that they probably would not need to be rewritten if the
definition changed.  However, the LRM would have to be changed in at least
three places.  A different attribute would need to be mentioned everywhere
POS is mentioned (along with its inverse).

Roger Racine
C.S. Draper Laboratory, Inc.
rjr1287@draper.com
(617) 258-2489