On Mon, 2012-07-30 at 20:33 +0200, Phillip Helbig wrote:
> > NAG Fortran does warn about the first of those programs at compile time:
> > Warning: testonly1.f90, line 7: RADIX explicitly imported into TEST but
> > not used
> OK, but how can it import something which is not an object declared in
> the module? At least it does this; apart from my compiler, a couple of
> linux ones give equivalent messages (i.e. none in this case).
USE accesses identifiers, not objects. An identifier can identify an
object, a type, a procedure (including by way of an operator symbol), or
a namelist. A procedure can be one defined by the program, or an
In the example
INTEGER :: I=RADIX(1)
END MODULE BLA
USE BLA, ONLY: I, RADIX
END PROGRAM TEST
RADIX is the name of the intrinsic function. Since the identifier
appears in BLA and doesn't have the PRIVATE attribute, the identifier
can be accessed by a USE statement in the main program. Of course, the
name carries along what it identifies, so the processor knows that the
name RADIX, when it appears in the main program, is the name of the
intrinsic function RADIX, not a data object.
According to subclause 220.127.116.11 of the 2008 standard, intrinsic
procedures always have explicit interface, so IMPLICIT NONE doesn't
apply to RADIX.
One way to think of intrinsic procedures, which is not the model in the
standard but works nonetheless, is to think of intrinsic procedures as
being defined by an hypothetical host environment that encloses every
program unit, and from which they are accessed by host association.
Using IMPLICIT NONE in an internal or module procedure does not cause
the names of host associated entities to be inaccessible.
To go a step away from the problem, the accessibility attributes PUBLIC
and PRIVATE refer to identifiers, not the entities they identify. So if
you had a module such as
integer, public :: A
integer, private :: B
equivalence ( A, B )
end module M
the identifier A, and therefore the object A would be accessible by USE
association, while the identifier B would not be. Making B private does
not affect the accessibility of the object it identifies, if it can be
accessed by a different public identifier.