barmar@think.UUCP (11/23/87)
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
mcdonald@uxe.cso.uiuc.edu (11/25/87)
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 >This somehow no longer seems like a comp.lang.c issue.. This is not a C issue, but neither is it Fortran, as the example is not a legal Fortran program. Any possible run-time behaviour is possible: Fortran does not define it. The reason is that Fortran does not permit an actual argument (the "3" in FUNC(3) ) to be modified in FUNC (the K=5 line). It is up to the programmer not to write erroneous programs. (okay, I am wearing a flameproof suit) Doug McDonald
gwyn@brl-smoke.ARPA (Doug Gwyn ) (11/27/87)
In article <47000023@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >In article <6715@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: [example deleted] >This is not a C issue, but neither is it Fortran, as the example is not a >legal Fortran program. Any possible run-time behaviour is possible: Fortran >does not define it. The reason is that Fortran does not permit an actual >argument (the "3" in FUNC(3) ) to be modified in FUNC (the K=5 line). >It is up to the programmer not to write erroneous programs. (okay, >I am wearing a flameproof suit) I wasn't putting this forward as an example of a correct program, but rather as a counterexample in an argument against the notion that Fortran parameters "are" always passed by reference. The only way I know of for an implementation to detect that I was trying a no-no (assuming the reference and definition of the function to be in separately-compiled modules) would be through the use of dope vectors or some similar mechanism, but then that too would make my point, being clearly not pure call by reference. Expressions are handled differently from variables in this regard, precisely BECAUSE they have no address to be referenced. To make this somewhat C-pertinent, I view C's adoption of call by value for all (well, almost all) function parameters, made feasible by having decent pointer types available, as a significant design improvement over Fortran and Pascal.