Path: csiph.com!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Thomas Koenig Newsgroups: comp.compilers Subject: Re: modifying constants in Fortran and elsewhere Date: Sat, 15 Jul 2023 10:57:48 -0000 Organization: Compilers Central Sender: johnl%iecc.com Approved: comp.compilers@iecc.com Message-ID: <23-07-006@comp.compilers> References: <23-07-003@comp.compilers> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="41153"; mail-complaints-to="abuse@iecc.com" Keywords: history, errors, architecture, comment Posted-Date: 15 Jul 2023 17:09:59 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:3502 gah4 schrieb: > A potential bug since the earliest days of Fortran is passing a > constant to a subroutine, and then changing the value of the dummy > argument. > > In at least some Fortran system, this modifies the value of a constant > used other places in a program. Could come in handy if the value of PI should change during the excecution of the program :-) This is a consequence of the standard /360 calling convention. Both arguments and local variables were put in close proximity to the code, if posssible within the range of a base register. It was all read-write, and the compiler optimized duplicate constants. (The explanation above is only for non-reentrant code, which was the usual case for FORTRAN, but they could be made to use reentrant code using a compiler option). > As this was known when PL/I was designed, it is defined such that > modifiable constants are passed to called procedures. C avoids it by > not allowing the & operator on constants. (Though K&R allows > modification of string constants.) You can still try by passing a pointer to a const variable, but chances are you will get a segfault when you try to modify it. > Somehow, in all the years, that feature was never added to Fortran. Fortran has the VALUE attribute for dummy variables now, which generates a local copy of the variable. Compilers differ on how they implement it; passing VALUE arguments as actual value, like C usually does, or passing a pointer and making a local copy are both valid choices. > It is easy to write programs and test for it, but I wonder if there > are any stories for real program that had this bug, and even better, > stories about the difficulty of finding it, or problems caused by it. I actually got bitten by that while using a mainframe for scientific work as a student. It's been a few decades, so I don't recall too many details. It was difficult to find, but I was paid by the hour, so I didn't mind too much :-) [The constant stomping issue far predates S/360. As soon as Fortran II added subroutines on the 704, there were constant arguments you could change by mistake. The problem is that it took quite a while for people to sort out the differences among call by reference, call by value, and call by copy in/out. Fortran on the 70x and S/360 user reference for array arguments, copy in/out for scalars. Algol 60 tried to define its argument passing in an elegant way, and accidentally invented call by name when they meant call by reference. -John]