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,483a6309b2450e41 X-Google-Attributes: gid103376,public From: mfb@mbunix.mitre.org (Michael F Brenner) Subject: Re: Ada 95 case statement incompatibility? Date: 1996/08/27 Message-ID: <4vvmra$k3t@linus.mitre.org>#1/1 X-Deja-AN: 176841587 references: <4vv4bs$hb8@erlang.praxis.co.uk> organization: The MITRE Corporation, Bedford Mass. newsgroups: comp.lang.ada Date: 1996-08-27T00:00:00+00:00 List-Id: Another difference between 83 and 95 that was not documented is the later rule that generics instantiated with signed numbers are incompatible with generics instantiated with unsigned numbers. This makes the systems programming of device drivers almost impossible to program compatibly between 83 and 95, and also (ultimately) led to the decision that we don't have access to the upper bit of an n-bit signed or unsigned number during conversions. This loss of a bit can have an efficiency effect, as well as the workarounds it forces one to place in one's code. For example, in one current Ada-95 compiler, the unchecked conversion one would think of to work around the problem actually generates code! The original Ada 9X requirement to handle and give the systems programmer access to all the bits was not handled here. Those Ada 83 implementations that gave unsigned numbers (by overloading modular operations onto a signed number type) are not compatible in either regular code (documented in the list of incompatibilities) or generically (not documented in the list of incompatibilities).