Xref: utzoo comp.lang.fortran:4015 comp.sys.sgi:6503 Path: utzoo!attcan!uunet!world!burley From: burley@world.std.com (James C Burley) Newsgroups: comp.lang.fortran,comp.sys.sgi Subject: Re: archiving block data subroutines... Message-ID: Date: 26 Oct 90 11:27:25 GMT References: <1990Oct22.033107.5159@ux1.cso.uiuc.edu> <2208@key.COM> Sender: burley@world.std.com (James C Burley) Distribution: comp Organization: The World Lines: 105 In-Reply-To: sjc@key.COM's message of 26 Oct 90 05:18:55 GMT In article <2208@key.COM> sjc@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@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@world.std.com