Timeline for Are there any primary sources for the “passing constant by reference” behavior in old Fortran compilers?
Current License: CC BY-SA 4.0
22 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 1, 2021 at 19:00 | history | unprotected | user3840170 | ||
| May 28, 2021 at 5:36 | history | protected | user3840170 | ||
| May 27, 2021 at 21:39 | review | Suggested edits | |||
| May 28, 2021 at 0:06 | |||||
| May 27, 2021 at 4:12 | answer | added | Thomas Perry | timeline score: -4 | |
| May 26, 2021 at 23:40 | comment | added | dave | Re: VMS FORTRAN - the %VAL construction (and others) existed so that FORTRAN could call routines written in other languages (principally, I suppose, BLISS and MACRO-32) which might have value arguments. | |
| May 26, 2021 at 21:58 | answer | added | scruss | timeline score: 4 | |
| May 26, 2021 at 4:32 | answer | added | Leo B. | timeline score: 9 | |
| May 26, 2021 at 4:01 | answer | added | Thomas Perry | timeline score: 1 | |
| May 25, 2021 at 12:23 | comment | added | TooTea |
@alephzero That's not true. If there's no intent attribute (or the procedure doesn't have an explicit interface at all), the default isn't intent(inout), but no intent at all (thus no compile-time checking). Doing it any other way would break loads and loads of existing and future code.
|
|
| May 25, 2021 at 12:20 | answer | added | TooTea | timeline score: 6 | |
| May 25, 2021 at 2:28 | comment | added | vonbrand | I distinctly remember a hard-to-catch bug in one of my FORTRAN IV programs on IBM S/360 in the '70s where the constant 1 mysteriously behaved like 2... because constant 1 was passed as an argument to a SUBROUTINE that incremented it. Fond memories... | |
| May 24, 2021 at 23:32 | comment | added | Walter Mitty | If you can find a book by Daniel McCracken, there's a good chance he discusses this. | |
| May 24, 2021 at 16:58 | comment | added | supercat | I've seen YouTube videos about people using a FORTRAN compiler on a rather ancient computer (IBM 1401 I think). I wonder if those people could run a program that would actually demonstrate the behavior? That would be the most definitive "primary source". | |
| May 24, 2021 at 11:07 | comment | added | alephzero | This is a non-issue in modern Fortran (Fortran 90 or later), where you can declare parameter use as "in", "out" or "inout" in an interface block in the calling routine, and the compiler will then check for violations. If you don't declare an interface, the default is "inout" so attempting to use a constant argument is always a compilation error. | |
| May 24, 2021 at 10:25 | history | edited | user3840170 | CC BY-SA 4.0 |
tag, grammar (swapped adjective for a noun), contemporaneous (unless you really meant modern?)
|
| May 24, 2021 at 7:08 | answer | added | Mark Williams | timeline score: 5 | |
| May 24, 2021 at 7:05 | comment | added | Mark Williams | My company produced a suite of Fortran tools in the 90s called PlusFort, and I remember this being a situation it looked out for. | |
| May 24, 2021 at 0:22 | comment | added | alephzero | IIRC, the IBM Fortran G and H compilers for S/360 and S370 had this feature, but (1) the "constant pool" was local to a subroutine/function, or a least local to a separate complication unit and (2) the exact (undetected but wrong) behavior depended on the optimization level you specified. No idea where if was documented (if anywhere) but it was a well known "programming bug" at the time. | |
| May 23, 2021 at 23:26 | comment | added | njuffa |
DEC Fortran 77 allowed, with some limitations, overriding the default behavior (pass by reference) with %VAL (arg).
|
|
| May 23, 2021 at 23:13 | comment | added | texdr.aft | @njuffa Here's a compiler from 1966 that explicitly avoids the problem by passing constants by value: bitsavers.org/pdf/honeywell/series200/charlie_gibbs/… (page 6-11 (page 129 in the PDF)). This isn't really relevant; I just thought it was interesting. | |
| May 23, 2021 at 22:46 | comment | added | njuffa |
This was definitely still a feature of Fortran-77 compilers on PCs in the 1980s. To my knowledge, gfortran still uses this design, except that the constant pool is now mapped to read-only storage, so it is no longer possible to overwrite constants (which could be a source of hard-to-find bugs in the past!). I have searched manuals for old IBM and VMS Fortran compilers for the past 40 minutes, but have been unable to find any language that spells out these inner workings in explicit detail.
|
|
| May 23, 2021 at 21:34 | history | asked | texdr.aft | CC BY-SA 4.0 |