Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!tut.cis.ohio-state.edu!snorkelwacker.mit.edu!ai-lab!life!burley From: burley@pogo.ai.mit.edu (Craig Burley) Newsgroups: comp.lang.fortran Subject: Re: archiving block data subroutines... Message-ID: Date: 27 Nov 90 13:38:32 GMT References: <1990Nov22.074157.15813@agate.berkeley.edu> <7388@hub.ucsb.edu> <69366@bu.edu.bu.edu> Sender: news@ai.mit.edu Organization: /home/fsf/burley/.organization Lines: 107 In-reply-to: shank@buphy.BU.EDU's message of 26 Nov 90 19:59:54 GMT In article <69366@bu.edu.bu.edu> shank@buphy.BU.EDU (Jim Shank) writes: I always thought the way to do this was to declare the Block Data subprogram EXTERNAL in the main routine: PROGRAM MAIN EXTERNAL BLKDAT . . . STOP This forces the linker to include the Block data subprogram. Not according to the standard, but yes, I agree this is the most standard-conforming way to deal with things, both from the user's and the implementor's point of view. The problem is that systems that "extend" Fortran by providing certain weird nonstandard things like source files that contain multiple program units and, in this case, libraries from which only program units referenced by the program currently being linked/loaded are actually loaded, fail to take into account and thus implement in an obvious and standard-acceptable way certain Fortran facilities like BLOCK DATA. (Yes, I know these are very common things, but their behaviors aren't even discussed in the standard.) As I've pointed out before, the ONLY standard way to pre-initialize (DATA) variables in common areas is to: use named commons; and initialize them via DATA in BLOCK DATA program units. A system that provides libraries and yet does not implement in the expected way the standard extension (that by the way in the standard has NO explanation I can find) you showed in the above example by ensuring that any BLOCK DATA FOO in a library is loaded/linked if at least one other program unit that is loaded/linked contains an EXTERNAL FOO statement is, in my opinion, not a complete implementation of Fortran. It may be an ANSI-conforming implementation, but that's a different question. For example, an implementation may be ANSI-conforming as long as all your program units are in a single source file, but not if you put them in separate source files even though that implementation handles multiple sources (and thus objects) in a load/link command for other languages. Even though it appears to handle Fortran this way also, and works in many cases, the fact that, say, linkage involving user-defined procedures having the same names as intrinsics does not work still wouldn't prevent the implementation from being ANSI-conforming as long as the problem didn't exist in SOME method of writing Fortran code (in my example, one big source file with all the program units, hence one big object module). So a system that had such a problem could be ANSI-conforming but, in my opinion, would not be complete Fortran in terms of the natural combination of its capabilities (multiple source files + ANSI Fortran support should = ANSI Fortran support using multiple source files). That is why I assert that systems failing to load/link BLOCK DATA FOO from a library when at least one load/linked program unit says EXTERNAL FOO are not complete Fortran, because they a) have libraries, b) may conform to ANSI FORTRAN 77, but c) do not conform to ANSI FORTRAN 77 in the natural way when libraries are used in certain standard ways. Such systems require the programmer either to use nonstandard constructs within their programs (which in itself should be a clear argument that these systems are not complete Fortran) or use extraordinary facilities like special specifications when loading/linking or generating the library (which is redundant since there's an ANSI feature provided that should be usable; and if the programmer does not know this and uses the extraordinary facilities, he or she might well be producing nonportable code without knowing it). Note that this does not mean I necessarily have a beef with a Fortran system implementation (or implementor) that fails to deal with this feature, IF the implementor has no control over the loader/linker (i.e. it comes from another vendor and is highly inflexible or primitive). However, I DO have a beef with people who say "we can't have EXTERNAL FOO force FOO to be loaded/linked since it might not be a BLOCK DATA (and we can't tell the difference when we need to) and we don't want to put anything in the executable image that is not actually referenced except possibly via EXTERNAL". This is WRONG. They certainly CAN force FOO to be loaded/linked, because a) I doubt many programs ever use EXTERNAL without actually referencing the name, and b) assuming they provide some nonstandard or nonportable means to solve the BLOCK DATA problem, they should instead solve it according to the standard and relegate designations like "I know I said EXTERNAL FOO, perhaps, but I don't really need it if I don't actually reference it" to the realm of nonstandard and nonportable behavior. I hold this position simply because failing to optimally omit an EXTERNALed procedure from a loaded/linked program that doesn't actually reference it has no effect on the correctness of a program, and hence can be relegated to the category of problems solved via nonstandard and nonportable means. On the other hand, failing to load/link an EXTERNALed BLOCK DATA in a loaded/linked program definitely CAN and most often WILL affect the correctness of the program. Anyone holding the opposite position in light of these facts (assuming these are facts, i.e. I'm not simply mistaken about something) should, in my opinion, not be writing compilers, linkers, operating systems, and so on -- anything that has a "standard" of sorts for it. Nor should they be selling or manufacturing such products. They don't have the temperment for it -- they'd do better at end-user applications, where saving a bit of space or time at the expense of full generality might be ok as long as they know when they don't need full generality. Myself, I think I have not yet developed the temperment for end-user programming: i.e. this is not a criticism of one's person, but of whether they're in the right field of labor within the software industry. There's plenty of room for all of us! James Craig Burley, Software Craftsperson burley@ai.mit.edu