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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6a0391eb7e0327d5 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-08 16:41:33 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!wn11feed!wn13feed!wn12feed!worldnet.att.net!bgtnsc04-news.ops.worldnet.att.net.POSTED!not-for-mail Reply-To: "James S. Rogers" From: "James S. Rogers" Newsgroups: comp.lang.ada References: <86isvuzabx.fsf@hoastest1-8c.hoasnet.inet.fi> Subject: Re: Ada style of passing 'in' parameters considered dangerous? X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: <0th1a.41024$zF6.2804045@bgtnsc04-news.ops.worldnet.att.net> Date: Sun, 09 Feb 2003 00:41:32 GMT NNTP-Posting-Host: 12.86.36.100 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc04-news.ops.worldnet.att.net 1044751292 12.86.36.100 (Sun, 09 Feb 2003 00:41:32 GMT) NNTP-Posting-Date: Sun, 09 Feb 2003 00:41:32 GMT Organization: AT&T Worldnet Xref: archiver1.google.com comp.lang.ada:33920 Date: 2003-02-09T00:41:32+00:00 List-Id: "Antti Sykari" wrote in message news:86isvuzabx.fsf@hoastest1-8c.hoasnet.inet.fi... > Hello, > > I recently asked in comp.compilers advice about implementing a > parameter passing policy for a rather close-to-machine language. My > suggestion for the method of passing 'in' parameters to procedures > was: Pass everything as readonly by default, and leave the > by-reference/by-copy decision to the compiler. > > It was pointed out that Ada already has this kind of policy. In one > reply (<03-01-169@comp.compilers>), it was mentioned that it is a > time-bomb in Ada, since it permits the programmer to write code that > is erroneous but the compiler cannot detect this. Indeed, the > standard ([1]) says that if an object has been passed via an > unspecified parameter passing mechanism, is written via one access > path and read via another, "possible consequences are that > Program_Error is raised, or the newly assigned value is read, or some > old value of the object is read". > > For example, in the simplest case, a procedure can take a readonly > 'in' argument "arg1" of type X, and an "in out" argument of the same > type. Then, if it writes in arg2 and after that reads arg1, this might > cause a run-time error or other implementation-defined behavior -- but > only if the procedure is called with two identical arguments. > > Of course, the erroneous behavior might occur in a more subtle way, > which is not expected to happen. I just can't think of any realistic > example where this undefinedness would really hurt. > > My concerns here are: > > - Is this generally considered a dangerous thing in Ada (or in > general)? > > - Have you encountered a non-trivial real-life case where the > programmer has shot himself in the foot in the form of > implementation-defined behavior because of the error mentioned above? > I'd be interested to hear of any such cases. > > - If there are such cases, could it have been prevented by having > different policy in the language? Do you think it would've been > better to force the programmer to specify the parameter passing > mechanism, for example? Not at all. In Ada an IN parameter is treated as a constant within the subprogram it is passed to. This eliminates the ability to shoot yourself in the foot with an IN parameter. An OUT or IN OUT parameter can be passed by value or by reference. The language provides no rules about this. The difference between the two in Ada is that an OUT parameter has no reliable initial value, while an IN OUT parameter does. In fact compiler writers are quite reasonable about their chosen passing mechanisms. In general, any value larger than a register is passed by reference. All other values may be passed by copy or by reference. There can be no race condition for either situation in a normal subprogram, since the called subprogram will execute in the same task as the calling subprogram. Calling a task entry may involve passing data. This is a form of communication between tasks. In Ada this happens as part of a "rendezvous", where the two tasks synchronize at the point of communication, again eliminating a race condition. Calling a protected operation is another option for inter-task communication. Again, protected operations execute within the calling task, or its proxy in the case of protected entries. I have never seen a case where Ada parameter modes have shot the programmer in the foot. Ada parameter passing modes are a lot safer to use than the rules found for Java. In Java all primitive types are passed by value and all objects are passed by reference. You have no choice. This does cause genuine problems in program design for Java, particularly when you want to modify the value of a primitive parameter. Since it is impossible to pass an object by value you have the ever present danger of unexpected side effects in Java method calls. Java does not have a direct equivalent of the Ada rendezvous, nor does it provide an equivalent of Ada protected operations. Java produces concurrency with a lot more surprises. Jim Rogers