archiving block data subroutines...

[James C Burley]

In article <2208 at key.COM> sjc at key.COM (Steve Correll) writes:

   James Craig Burley writes:
   > ...I believe if you look into
   > the history of the F77 standard, you'll find that the reason Page 8-9 lines 30
   > and 31 allow block data subprogram names in the EXTERNAL statement was to
   > accommodate systems allowing linking of libraries that needed a means to
   > allow procedures in a library to specify that they also needed a corresponding
   > BLOCK DATA program unit from that same library.
   > ...It stands to reason, therefore, that anyone designing a new Fortran system
   > and wishing to be standard-conforming would support both the letter and the
   > spirit of the standard...any responsible developer would interpret it that
   > way...

   I am acquainted with language-independent compiler optimizers which delete
   unreferenced global imports, causing EXTERNAL BDATA to vanish without a trace.
   Perhaps you are not accustomed to such aggressive optimization. Clearly it's
   a matter of taste, but around here we tend to regard complaints about such
   deletions with the same sympathy we extend to complaints about our not
   allocating unSAVEd local variables in memory: if the standard doesn't say you
   can rely on it, please don't.

   Consider that the Fortran 77 standard says (2.12) that when a procedure
   _reference_ is _executed_, the procedure must be "available" (the Fortran 77
   circumlocution to avoid talking about "linking"). Can anyone find a provision
   in the standard which says that the appearance of a procedure name in an
   EXTERNAL statement requires the procedure to be "available"? I can't. In its
   absence, I can imagine a perverse user arguing that the following program is
   standard-conforming even if X is not available:

	   EXTERNAL X
	   END

   and complaining that a processor which refuses to construct an executable
   program in the absence of X fails to conform to Fortran 77!
   -- 
   sjc at key.com or ...{sun,pyramid}!pacbell!key!sjc 		Steve Correll

I am accustomed to extremely aggressive optimization, both that which has
been implemented and that which I've only thought about.

The program you show above, "EXTERNAL X;END", is indeed standard-conforming
even if X is not available, because X is not necessarily a procedure: in fact
it appears the standard requires that it must be a BLOCK DATA subprogram.
(Because in the main program unit, it is not referenced as a subroutine or
function, and a BLOCK DATA subprogram is the only alternative.)  Unfortunately,
the standard does not appear to specify the effect of specifying a BLOCK DATA
subprogram name in an EXTERNAL statement.  So it appears that your mythical
user complaining about a processor refusing to construct an executable
program in the absence of X indeed has a point: it is a valid program, and
X need not be present, even though I would argue a reasonable implementation
should complain that there is no BLOCK DATA X (via an error message from,
perhaps, a multi-language linker requiring the user to look up the message
in the Fortran book to yield the explanation that perhaps a BLOCK DATA X
is missing).

However, as I pointed out in my original posting, the only reasonably way
for an implementation to deal with "EXTERNAL FOO" where FOO is not referenced
anywhere else in the same program unit is for it to assume FOO is a BLOCK DATA
program unit and to ensure that, if it indeed turns out that FOO is found to
be a BLOCK DATA program unit, its initial values for variables in COMMON are
used for the program.  If FOO turns out to be a subroutine or function, an
implementation is free to ignore it, if it is capable of doing that while
still dealing with the possible BLOCK DATA FOO case instead.

Now, you can play language lawyer games -- like the company that said their
implementation was standard-conforming even though the STOP statement did
not in fact stop the program, because the standard didn't actually specify
what happens the moment after the program is "stopped" -- and say that an
implementation is standard-conforming that totally ignores EXTERNAL FOO
where FOO is otherwise unreferenced in the program unit.

However, if you are taking things this literally from a standards
perspective, then please note that there is NO STANDARD WAY to initialize
variables in common!  According to the standard, that can ONLY be done
via BLOCK DATA.  And a system that provides some mechanism whereby BLOCK DATA
can be ignored (the "library problem" that started all this), and yet
refuses to honor a clear accommodation in the standard to deal with the
problem, fails to honor the spirit of the standard, just as does one that,
when running a program saying "PRINT *,2.0*3.0", outputs "2.0" because
the standard doesn't actually specify precision requirements.

After all, if subroutines and functions need only be "available" when they
are actually "referenced" at run time, then (unless there's some wording to
override this assumption in the standard that I can't remember seeing offhand),
the same goes for BLOCK DATA in a system that implements everything using
libraries.  Yet there is NO WAY to "reference" a BLOCK DATA subprogram except
via the "EXTERNAL FOO" construct.

(And note that your reference to complaints about unSAVEd variables not
being SAVEd is, in my opinion, an invalid comparison in this context.
The spirit of the standard regarding BLOCK DATA is as I state above; whereas
the standard clearly states that you can't depend on the value of an
unSAVEd variable between procedure invocations.  People complaining about
a system not honoring the EXTERNAL FOO convention for ensuring the linking-in
of a BLOCK DATA FOO residing in a library have a very legitimate gripe,
language-lawyer games notwithstanding.  People who complain about unSAVEd
variables not retaining their values between procedure invocations are just
plain wrong; but note that many implementations nevertheless provide command-
line qualifiers to effectively force the SAVEing of all appropriate
variables, so given that so many implementations bend over backwards to
accommodate incorrect or very old code, why not deal with the relatively
trivial case of EXTERNAL FOO possibly referring to a necessary BLOCK DATA FOO?)

James Craig Burley, Software Craftsperson    burley at world.std.com