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 CrispinNewsgroups: 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. -------