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,4c08cfbd3f797c1c X-Google-Attributes: gid103376,public From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: simple question - how to emulate void * ? Date: 1998/10/24 Message-ID: #1/1 X-Deja-AN: 404601102 Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.camb.inmet.com References: Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1998-10-24T00:00:00+00:00 List-Id: Dale Stanbrough (dale@cs.rmit.edu.au) wrote: : ... : This is then a problem with Ada, that the legality of calling a routine in : a child package can be affected by the exact definition of a type defined : as "implementation defined". : ... : Perhaps it would have been better if the LRM specifically excluded these : operations from package System.Address, given the presence of : System.Storage_Elements. Perhaps we need to understand the rationale of : having : type Address is : vs. : type Address is private; : I certainly haven't hit this particular problem before, and it _is_ : an annoying "feature". Can anyone clarify this point for me? In RM95 we tried to balance the requirements for upward compatibility against the requirements for portability. In Ada 83, package System became a dumping ground for all kinds of non-portable stuff. In Ada 95, we tried to encourage vendors to put the non-portable stuff into implementation-defined children of System. In particular, RM95 13.7(36) and 13.7(37) permit implementation-defined additions to System, but encourage the use of children instead, and encourage declaring Address as a private type. However, vendors with a large installed Ada 83 base had to make certain choices based on their customer preferences. The adding operators on type Address involve such a choice. The net effect is that users who want to write portable code have to reckon with the possibility that package System might have extra stuff in it. Hence, minimize the use of "use" on package System. A "use" on package System.Storage_Elements (or a "use type" on System.Storage_Elements.Storage_Offset) should be safe and portable, since no implementation-defined additions are permitted to that package. : Dale -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA An AverStar Company