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