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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!igor!yoda!jls From: jls@yoda.Rational.COM (Jim Showalter) Newsgroups: comp.lang.ada Subject: Re: Reference vs. copy semantics in passing parameters Keywords: Ada Message-ID: Date: 18 Feb 91 00:36:28 GMT References: <5572@baird.cs.strath.ac.uk> <1991Feb13.211643.25777@rti.rti.org> <2725@sparko.gwu.edu> <2742@sparko.gwu.edu> Sender: news@Rational.COM List-Id: Yes, but you miss my point (I think?). It is not modification of the POINTER we are trying to prevent. We are trying to prevent modification of what the pointer points to, and there is currently no way to insure this in Ada. A doofus can break the rules with impunity. Why would it BE a pointer? Beats me, but these things do happen from time to time, and when they do it would be nice if the language made them safe. One gross thing that people do currently is give IN/OUT semantics to parameters on functions by passing a pointer and dereferencing it inside the function to modify what the pointer points to. There is no way to prevent this egregious behavior at present (note: many many people have also requested that 9x include IN/OUT's on functions, which would make the case for performing the trick just described even weaker). -- ***** DISCLAIMER: The opinions expressed herein are my own. Duh. Like you'd ever be able to find a company (or, for that matter, very many people) with opinions like mine. -- "When I want your opinion, I'll beat it out of you."