Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 11 Dec 1997 00:30:05 -0500 (EST)
From:      Brian Clapper <bmc@WillsCreek.COM>
To:        keyser@clio.rice.edu (Kevin Keyser)
Cc:        questions@FreeBSD.ORG
Subject:   Re: constant parameters in f2c/f77
Message-ID:  <199712110530.AAA00425@current.willscreek.com>
In-Reply-To: <9712101659.AA15757@clio.rice.edu>
References:  <9712101659.AA15757@clio.rice.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
Kevin Keyser wrote:

> I see what I would call a bug in f2c/f77 running on a 2.2.2R machine.
> The code below shows the behavior.  Looking at the C code produced
> by f2c I can understand why it happens, but does anyone know where
> something like this should be reported?
>
> Kevin
>
> =========================
>
>       WRITE(6,*) 2
>       CALL ALPHA(2)
>       WRITE(6,*) 2
>       END
>
>       SUBROUTINE ALPHA(I)
>       I = 1
>       END
>
> =========================
>
> fbsd % f77 test.f
> test2.f:
>    MAIN:
>    alpha:
> fbsd % ./a.out
>  2
>  1

Way back in college, when I was first learning FORTRAN 77 on a CDC Cyber
mainframe, someone demonstrated to me how you could modify supposed
constants in exactly the way you describe above.  Upon reading your
message, I could not recall, however, whether modifying a constant was
expressly disallowed by the standard or not, so I did some poking around
the net.  (I haven't actually programmed the language for more than a
decade.)  The FORTRAN 77 standard is online, if you care; you'll find one
copy here:

        http://kumo.swcp.com/fortran/stds_docs.html

In any case, I found a decent enough good description of why constants
might be modified, in a year-old post to "comp.lang.fortran" (courtesy of
DejaNews).  An excerpt is below.  To read the entire thread, go to DejaNews
(www.dejanews.com), create a search filter to search only
"comp.lang.fortran", and search for "modify & constant".

-----
Brian Clapper, bmc@WillsCreek.COM, http://WWW.WillsCreek.COM/
In America, any boy may become president and I suppose that's just one
of the risks he takes.
        -- Adlai Stevenson

---------- Begin excerpt from comp.lang.fortran

Subject:      Re: modify constant? f77 std?
From:         singular@oort.ap.sissa.it (Poll Dubh)
Date:         1996/10/30
Message-ID:   <557v27$dc9@sv8.ictp.trieste.it>
Newsgroups:   comp.lang.fortran

[ ... ]

1. The code is indeed erroneous according to the Fortran standard (was
already so in the 77 edition).

2. The standard does not specify the behaviour of erroneous programs.
Causing an exception is one possibility, but some processors will happily
let you overwrite the memory area where the constant is stored instead.
(For example, good old CDC machines with 60-bit CPU words had no way of
selectively protecting portions of the user address space against overwriting
by user code. The exception trigger would therefore have had to be implemented
in software, with unwanted overhead even for correct programs.)

3. I'm a little surprised to hear that the SGI, IBM XL and DEC compilers
would default to not storing constants in write-protected pages. The hardware
support is there, so if they don't do it (and I don't necessarily believe
the report that they don't) it's probably that some important customer has
legacy code that relies on modifying constants.

4. The example code was (deliberately?) obscuring the fact that the value
was overwritten by assigning the original value back to the string. That
could make you think that a good optimising compiler might have been able
to notice that fact in the routine and optimise away the assignment. Not
so, unless it can guarantee that tmpstr is never shorter than str (or
decides to test for that case, which is conceivable... Examining the
object code generated by the SGI, IBM and DEC compilers for that routine
is left as an exercise to the reader.)

---------- End excerpt from comp.lang.fortran



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712110530.AAA00425>