Re: Structure of large link libraries in f95

Richard Maine wrote:
Charles Russell <SPAMworFREEwor@xxxxxxxxxxxxx> wrote:


Richard E Maine wrote:


If one of the procedures in your library references another of the
procedures in the same library, you probably have an EXTERNAL statement
for it,

Why? Not in my own code. What for? I sometimes see external statements in other people's code that have no apparent purpose other
than documentation.


Well, there's the reason that's been stated in the standard pretty much
forever - without the EXTERNAL attribute you runthe risk of your code
failing if you ever use it on a compiler that has an intrinsic of the
same name. That includes compiler-specific intrinsics and intrinsics
added by new versions of the standard. Pretty much every version of the
standard has listed new intrinsics as a possible incompatibility with
old code unless the old code uses the EXTERNAL attribute.

For consistency, perhaps we need an "INTERNAL" statement. "EXTERNAL" is not an exact opposite of "INTRINSIC". For precision in the declaration, you might want to define an "INTERNAL" procedure with the same name as an "INTRINSIC" (although I guess it would be quite rare). "INTERNAL" can be assumed by prioritization, but this could promote self-documenting code. This is primarily in the interested of symmetry, but on the other hand, I'm not quite sure what an "EXTRINSIC" would be. For the use mentioned of passing the procedure name as an argument I'd prefer something like:

call subname ( address(<ProcedureName>) )

That's more clear than just declaring something as external in which case, you would probably want to declare a lot more about the interface (external now seems to me like it belongs as part of an interface definition).


And then there are cases like the one you mentioned below - you must use
the external attribute if you are passing the procedure as an actual
argument. Otherwise, the compiler has no way to guess that you meant a
pocedure - it will likely end up trying to pass an implicitly declared
local variable.... which isn't likely to workvery well if a procedure is
expected.


The following contains EXTERNAL statements in the way I normally use them in f77, and it seems to work OK inside a module:

use talk
external hellosub
call saywhat(hellosub)
end

module talk

contains

subroutine saywhat(what)
external what
call what()
return
end subroutine

subroutine hellosub()
write(6,*) 'hello'
return
end subroutine

end module talk


Really? That shouldn't work. I bet it won't with all compilers. You are
declaring hellosub to be external, but it isn't. It is a module
procedure instead of an external one.


I must admit that my understanding of "external" is limited to the fact
that whenever an argument is a function or subroutine, it must be declared external in the calling routine or the program crashes.


See above.



--

Gary Scott
mailto:garyscott@xxxxxxx

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Why are there two? God only knows.


If you want to do the impossible, don't hire an expert because he knows it can't be done.

-- Henry Ford
.

Relevant Pages

  • Re: DPROD issues
    ... a switch like that typically ... makes a compiler nonstandard in that mode. ... treatment of specific intrinsics is one ... subroutine sub1a ...
    (comp.lang.fortran)
  • Re: Structure of large link libraries in f95
    ... But since it is impractical to rerwite all my old code, a possible solution would be to scan it for the for new intrinsics. ... subroutine saywhat ... subroutine hellosub() ... declaring hellosub to be external, ...
    (comp.lang.fortran)
  • Re: Structure of large link libraries in f95
    ... you probably have an EXTERNAL statement ... failing if you ever use it on a compiler that has an intrinsic of the ... That includes compiler-specific intrinsics and intrinsics ... subroutine saywhat ...
    (comp.lang.fortran)
  • Re: EXTERNAL statement for subroutines: is it ever needed?
    ... external subroutine from a program unit, ... subroutine (Note that compilers can add intrinsics of their own, ... in confict with the compiler or the next version of the compiler, ... of the name - a module procedure or a name appearing in an interface ...
    (comp.lang.fortran)
  • Re: creating directories on the fly
    ... Although the SYSTEM subroutine does not belong to the Fortran ... >> standard, i don't get an indication that I'm using an extension... ... Calling subroutines is not an extension. ... > existing standard intrinsics to be transitioned into modules, ...
    (comp.lang.fortran)