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,a415d3a613d86a4e X-Google-Attributes: gid103376,public From: "Stanley R. Allen" Subject: Re: Ada Enumerations Date: 1997/12/04 Message-ID: <34873053.15FB@hso.link.com>#1/1 X-Deja-AN: 295296746 References: <662cs9$b34$1@newman.pcisys.net> <663j9f$e1l@mtinsc02.worldnet.att.net> <3485D2AE.3F54@hso.link.com> Organization: NASA, Kennedy Space Center Newsgroups: comp.lang.ada Date: 1997-12-04T00:00:00+00:00 List-Id: Robert Dewar wrote: > > I must say I don't see so much of a problem with Unchecked_Conversion for > replacing Enum_Rep unless you have a really hostile compiler. For types > like this, Unchecked_Conversion should work as expected in cases where > the number of bits of the source and target differs. At least you *hope* so; too bad for you if your application depends on it and the compiler doesn't do it right, or if you need to port to a "hostile" compiler. There being no rule for this in either Ada83 or Ada95 (and apparently no "implementation advice" to this effect in the new standard), it is perfectly permissible for compilers to implement unchecked_conversion in such a way that garbage is there if the sizes are mismatched, which is one of the potential uses of the new 'Valid attribute. There is no clean way to recover from this situation, either. Especially when porting, these are the anomalies that try men's souls. See my other post for other reasons to dislike UC for this. -- Stanley Allen mailto:s_allen@hso.link.com