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=2.1 required=5.0 tests=BAYES_05,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!amdahl!nsc!rfg From: rfg@nsc.nsc.com (Ron Guilmette) Newsgroups: comp.lang.ada Subject: Re: Dynamic Address Clauses?? Message-ID: <5172@nsc.nsc.com> Date: 15 Jun 88 21:19:08 GMT References: <5697@aw.sei.cmu.edu> <57900075@ada-uts> Reply-To: rfg@nsc.UUCP (Ron Guilmette) Organization: National Semiconductor, Sunnyvale List-Id: In article <57900075@ada-uts> stt@ada-uts writes: > >To me it seems kind of pointless to try and figure out a meaning >for an address expression which will probably never be accepted by >an Ada compiler. Granted, but it is my understanding that the new rules of the Ada implementa- tion game require the implementation of all of Chapter 13, unless the implementor can show (I guess to the AVF) that certain parts are not realistic for a given hardware/OS configuration. (The traditional example is, I believe, that it is OK not to supply TEXT_IO for a SBC which has only 8 segment led's for output devices.) I have seen the LMC ruling which states this. I can't think of any hardware feature (or lack thereof) which would make the implementation of dynamic address clauses for subprograms unrealistic, so I guess that EVERYBODY will have to start implementing them SOMEHOW! This is exactly the point I really started out to make; i.e. that ALL Ada implementors should be scared s---less that ACVC 1.11... 1.12... or whatever will actually TEST for this! I hope that we can get 13.5(5) nixed before it comes to that. -- Ron Guilmette National SemiConductor Internet: rfg@nsc.nsc.com Uucp: ...{pyramid,sun,amdahl,apple}!nsc!rfg