Re: modifying constants in Fortran and elsewhere

Thomas Koenig <tkoenig@netcologne.de>
Sat, 15 Jul 2023 10:57:48 -0000

          From comp.compilers

Related articles
modifying constants in Fortran and elsewhere gah4@u.washington.edu (gah4) (2023-07-10)
Re: modifying constants in Fortran and elsewhere tkoenig@netcologne.de (Thomas Koenig) (2023-07-15)
Re: modifying constants in Fortran and elsewhere DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2023-07-16)
Re: modifying constants in Fortran and elsewhere tkoenig@netcologne.de (Thomas Koenig) (2023-07-16)
Re: modifying constants in Fortran and elsewhere gah4@u.washington.edu (gah4) (2023-07-16)
Re: modifying constants in Fortran and elsewhere gah4@u.washington.edu (gah4) (2023-07-16)
Re: modifying constants in Fortran and elsewhere david.brown@hesbynett.no (David Brown) (2023-07-17)
Re: modifying constants in Fortran and elsewhere gah4@u.washington.edu (gah4) (2023-07-17)
| List of all articles for this month |

From: Thomas Koenig <tkoenig@netcologne.de>
Newsgroups: comp.compilers
Date: Sat, 15 Jul 2023 10:57:48 -0000
Organization: Compilers Central
References: 23-07-003
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

gah4 <gah4@u.washington.edu> 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]


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.