Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site mcgill-vision.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!harpo!decvax!genrad!panda!talcott!harvard!bbnccv!bbncca!linus!philabs!micomvax!musocs!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: net.bizarre
Subject: Modifying constants and recursion in FORTRAN
Message-ID: <139@mcgill-vision.UUCP>
Date: Tue, 3-Sep-85 17:36:30 EDT
Article-I.D.: mcgill-v.139
Posted: Tue Sep  3 17:36:30 1985
Date-Received: Sun, 8-Sep-85 04:41:12 EDT
Organization: McGill University, Montreal
Lines: 26

> Modern techniques of flow analysis could theoretically catch this sort of
> trap in FORTRAN - *if* FOO were in the same source module as all calls
> to it.

     You could catch such things even when FOO and its caller are not in
the same source module, *provided* you put it in the linker rather  than
the compiler (and  have the compiler keep enough information around that
the linker can do something useful).

> ......  Another solution (depending on machine architecture, memory
> management, and OS design) would be to place all constants in a read-only
> data area.  Attempts to change constant values would either be ignored or 
> generate a run-time error.  (Anyone know of compilers/systems that do either?)

     I do.  VAX/VMS FORTRAN will accept the source  code, even when it's
all in one file, and will produce an access violation at run-time.

     (No, I don't use VMS....not since we got UNIX).
-- 
					der Mouse

{ihnp4,decvax,akgua,etc}!utcsri!mcgill-vision!mouse
philabs!micomvax!musocs!mcgill-vision!mouse

Hacker: One responsible for destroying /
Wizard: One responsible for recovering it afterward