Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site ecsvax.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!mcnc!ecsvax!dgary From: dgary@ecsvax.UUCP (D Gary Grady) Newsgroups: net.lang Subject: Re: Constants in subroutine calls Message-ID: <468@ecsvax.UUCP> Date: Mon, 7-Jan-85 12:37:34 EST Article-I.D.: ecsvax.468 Posted: Mon Jan 7 12:37:34 1985 Date-Received: Wed, 9-Jan-85 05:58:24 EST References: <5143@rochester.UUCP> Organization: Duke U Comp Ctr Lines: 44 <> The FORTRAN code CALL FOO(A, 5, B) or some such calling a routine like this: SUBROUTINE FOO(X, Y, Z) .. Y = 1 .. RETURN END results in the constant 5 being changed to 1 in the rest of the program. The original poster had resorted to never using a constant in a subroutine call to get around this bug. But the fact is that it IS a compiler bug which existed in a number of early FORTRAN compilers but which I thought had long since been removed. An actual parameter (argument) in a CALL statement can be a variable, a subprogram name, a statement number (preceded by an asterisk), or an expression. A numerical constant is a degenerate case of an expression. All expressions should be dealt with by copying the result into a work area and passing a pointer to that. This has the nice side effect that a variable can be passed on a call-by-value basis simply by enclosing it in parentheses. I suspect the bad behavior of allowing constants to be altered by subroutine calls may stem from a cute trick in the compiler's lexical analyser. Constants can be inserted into the symbol table as self-defining "initialised variables." If this is done, statements such as 1 = 2 will work! This would no doubt bring much amusement to the denizens of net.math, but *I* am not amused. (That's ~:-) in standard notation.) Oh, well... -- D Gary Grady Duke University Computation Center, Durham, NC 27706 (919) 684-4146 USENET: {decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary