Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!ima!think!barmar
From: barmar@think.UUCP
Newsgroups: comp.lang.c,comp.lang.misc
Subject: call by address (was Re: compilers and linkers)
Message-ID: <12114@think.UUCP>
Date: Mon, 23-Nov-87 14:25:30 EST
Article-I.D.: think.12114
Posted: Mon Nov 23 14:25:30 1987
Date-Received: Thu, 26-Nov-87 03:52:13 EST
References: <33890@sun.uucp> <387@sdcc15.UUCP> <180@sdti.UUCP> <11772@orchid.waterloo.edu> <6715@brl-smoke.ARPA>
Sender: usenet@think.UUCP
Reply-To: barmar@sauron.UUCP (Barry Margolin)
Followup-To: comp.lang.misc
Organization: Thinking Machines Corporation, Cambridge, MA
Lines: 34
Xref: utgpu comp.lang.c:5256 comp.lang.misc:859

In article <6715@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>	DO 10 I = 1, 2
>10	WRITE (*,*) FUNC(3)
>	END
>	LOGICAL FUNCTION FUNC(K)
>	INTEGER K
>	IF (K .EQ. 3) THEN
>		K = 5
>		FUNC = .TRUE.
>	ELSE
>		FUNC = .FALSE.
>	ENDIF
>If all parameters are truly passed by address, then the constant "3"
>would be changed for I.EQ.1 and therefore the second invocation of
>FUNC would return .FALSE.  

It doesn't have to do that.  It depends on what the "address" of a
constant is.  Except for some early, buggy ones, most call-by-address
implementations treat a literal parameter as an expression: the value
is pushed on the stack, and the address of the stack temporary is
passed to the subroutine.  If the parameter is assigned to, it is this
stack temporary that is changed, not the original in the literal pool.
But it is still the case that the parameter is being passed by address.

>This somehow no longer seems like a comp.lang.c issue..

I agree.  I've directed followups to comp.lang.misc.

---
Barry Margolin
Thinking Machines Corp.

barmar@think.com
seismo!think!barmar