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
drw@culdev1.UUCP (Dale Worley) (11/25/87)
barmar@think.COM (Barry Margolin) writes: | >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 Fortran II language consistently treated constant arguments by passing the address of the original constant. Since all occurrances of one constant value were treated the same, it made for some hard to find bugs. The language manual pointed out that using constants for arguments that were assigned to was invalid. They wised up when they wrote Fortran IV. Dale -- Dale Worley Cullinet Software ARPA: culdev1!drw@eddie.mit.edu UUCP: ...!seismo!harvard!mit-eddie!culdev1!drw If you get fed twice a day, how bad can life be?
phil@osiris.UUCP (Philip Kos) (11/25/87)
In article <1783@culdev1.UUCP>, drw@culdev1.UUCP (Dale Worley) writes: > The [FORTRAN II] language manual pointed out that using constants for > arguments that were assigned to was invalid. They wised up when they > wrote Fortran IV. Dale, who are "they"? Anyway, this is an *implementation* bug, not a design bug. The RT-11 FORTRAN IV compiler I used on LSI-11 systems as recently as 1982 (RT-11 v4? I'm not sure) still had this bug; I know, I tested it myself to see. :-) ...!decvax!decuac!\ Phil Kos ...!uunet!mimsy!aplcen!osiris!phil The Johns Hopkins Hospital ...!allegra!/ Baltimore, MD
drw@culdev1.UUCP (Dale Worley) (11/30/87)
phil@osiris.UUCP (Philip Kos) writes: | In article <1783@culdev1.UUCP>, drw@culdev1.UUCP (Dale Worley) writes: | > The [FORTRAN II] language manual pointed out that using constants for | > arguments that were assigned to was invalid. They wised up when they | > wrote Fortran IV. | | Dale, who are "they"? Anyway, this is an *implementation* bug, not a | design bug. No, it's a design bug, since actually using the construction was forbidden in FORTRAN II, the compiler wasn't required to handle it in any decent way. | The RT-11 FORTRAN IV compiler I used on LSI-11 systems as recently as | 1982 (RT-11 v4? I'm not sure) still had this bug; I know, I tested it | myself to see. :-) If the compiler claims to be FORTRAN *IV*, then it's an implementation bug. Dale -- Dale Worley Cullinet Software ARPA: culdev1!drw@eddie.mit.edu UUCP: ...!seismo!harvard!mit-eddie!culdev1!drw If you get fed twice a day, how bad can life be?