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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f70e7a457bf23e69 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-03-25 00:28:18 PST Path: nntp.gmd.de!news.rwth-aachen.de!news.rhrz.uni-bonn.de!news.uni-stuttgart.de!rz.uni-karlsruhe.de!xlink.net!howland.reston.ans.net!newsjunkie.ans.net!butch!cliffy.lfwc.lockheed.com!l107353 From: l107353@cliffy.lfwc.lockheed.com (Garlington KE) Newsgroups: comp.lang.ada Subject: Re: Optimizing and Constraint Checks Date: 24 Mar 1995 20:15:28 GMT Organization: Lockheed Missiles and Space Co. Message-ID: <3kv990$o7d@butch.lmsc.lockheed.com> References: NNTP-Posting-Host: cliffy.lfwc.lockheed.com X-Newsreader: TIN [version 1.2 PL2] Date: 1995-03-24T20:15:28+00:00 List-Id: Ed Bruce (edward@igate1.hac.com) wrote: : I am currently attempting to implement a safe, portable : Unchecked_Conversion of an enumerated type to integer and from an integer : type back to the enumeration. The following code shows the current : solution, the question raised by one engineer is can we guarantee the the : return statement in the To_Enum function is portable. That is may a : compiler optimize away the ENUM'Pos and ENUM'Val and effectively eliminate : the constraint check. I think your first portability problem is whether the ENUM will fit into an INTEGER. My compiler manual says: "Objects of enumeration types are allocated one word when no representation specification is given. If a specification is given that uses values in the range of LONG_INTEGER (but outside the range of INTEGER), objects will be allocated in double words. Second, I could definitely see a compiler optimizing away 'Val('Pos). 'Valid would be a better attribute here. Third, if an enum spec is used, I'm not sure what happens if there are holes in the underlying number sequence. The LRM says that CONSTRANT_ERROR is raised if X'Val is not in the _range_ T'POS(T'BASE'FIRST) .. T'POS(T'BASE'LAST). If it's in range, but not a valid representation, I suspect different compilers might behave differently. -------------------------------------------------------------------- Ken Garlington GarlingtonKE@lfwc.lockheed.com F-22 Computer Resources Lockheed Fort Worth Co. If LFWC or the F-22 program has any opinions, they aren't telling me.