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,eb64de1902329f4f X-Google-Attributes: gid103376,public From: eachus@spectre.mitre.org (Robert I. Eachus) Subject: Re: Record -> Array in Ada Date: 1996/08/20 Message-ID: #1/1 X-Deja-AN: 175368256 references: <321991BE.41C67EA6@mailgw.sanders.lockheed.com> organization: The Mitre Corp., Bedford, MA. newsgroups: comp.lang.ada Date: 1996-08-20T00:00:00+00:00 List-Id: In article dmarshal@netcom.com (Dave Marshall) writes: > *FROWNERZ*, sometimes we are prevented from doing the cool things that > work. LRM 13.5(8): > "Address clauses should not be used to achieve overlays of objects or > overlays or program units. Nor should a given interrupt be linked to > more than one entry. Any program using address clauses to achieve > such effects is erroneous." Hmmm. If that statement prevents you from doing something that works, try the Ada 95 wording: "If an Address is specified, it is the programmer's responsibility to ensure that the address is valid; otherwise, program execution is erroneous." There is no change in the semantics from Ada 83 to Ada 95, just a realization that the meaning of erroneous here exists only in the programmer's head. If the programmer defines the behavior as working, it is not erroneous, but that determination is way outside the bounds of the RM. Also, in Ada 95 the Unchecked_Conversion approach is much better defined. But again, whether the actions correspond to the programmer's intent is very implementation specific. Unchecked conversion of hidden fields and dope vectors can ruin your whole day--or make your job easier. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is...