Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!dcdwest!ittvax!decvax!genrad!mit-eddie!godot!harvard!seismo!brl-tgr!tgr!MRC@SU-SCORE.ARPA
From: Mark Crispin 
Newsgroups: net.unix-wizards
Subject: Re:  smart compilers
Message-ID: <7024@brl-tgr.ARPA>
Date: Sat, 5-Jan-85 15:26:24 EST
Article-I.D.: brl-tgr.7024
Posted: Sat Jan  5 15:26:24 1985
Date-Received: Tue, 8-Jan-85 04:42:27 EST
Sender: news@brl-tgr.ARPA
Organization: Ballistic Research Lab
Lines: 16


     I may be mistaken, but I believe according to the standards it is
not only "poor style" to change a constant which was passed to a subroutine,
it is also undefined what the behavior of the system after that should be.

     In any case, the object code from the TOPS-20 Fortran compiler is not
the only one where the value of a constant is changed as a result of such
practice.  This particular sort of bug is fairly well-known.

     There are various flavors of Fortran compilers on 10/20 and IBM systems
which will check for trying to do this sort of thing at runtime (also check
for out-of-bounds array references, remember the neat tricks we did with
those??), but that code introduces a *lot* of overhead.  You really have no
hope for catching this at compile-time; the earliest you can do it is when
linking the modules together.
-------