Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
This community is designed for sharing of public information. Please do not share Intel or third-party confidential information here.
27159 Discussions

Potential aliasing risk with derived types and type-bound procedures

OP1
New Contributor I
307 Views

I read Steve's "I've come for an argument" (parts I/II) excellent blog post... and now I am feeling a bit queasy about this sample code:

MODULE M
IMPLICIT NONE (TYPE, EXTERNAL)
TYPE :: T
    INTEGER :: I, J
    CONTAINS
        PROCEDURE :: PROC => T_PROC
END TYPE T
CONTAINS
    SUBROUTINE T_PROC(SELF,K)
    CLASS(T), INTENT(IN) :: SELF
    INTEGER :: K
    K = SELF%I
    END SUBROUTINE T_PROC
END MODULE M

PROGRAM P
USE M
IMPLICIT NONE (TYPE, EXTERNAL)
TYPE(T) :: MYVAR
MYVAR%I = 1
CALL MYVAR%PROC(MYVAR%J)
WRITE(*,*) MYVAR
END PROGRAM P

In the main code, the actual argument associated with the second dummy argument of T_PROC is a component of MYVAR.

The compiler does not complain (I don't see how this could be detected at compile-time) and the code runs as intended. My question is therefore (1) is this legal fortran; (2) is this a terrible practice to avoid as much as possible; (3) it's ok to do this as long as there is no aliasing/self-referencing of the type components themselves (note that I would feel more comfortable with this if the INTENT of SELF in T_PROC was INOUT).

Any thoughts?

0 Kudos
4 Replies
FortranFan
Honored Contributor II
296 Views
@OP1 wrote:
.. My question is therefore (1) is this legal fortran; (2) is this a terrible practice to avoid as much as possible; (3) it's ok to do this as long as there is no aliasing/self-referencing of the type components themselves (note that I would feel more comfortable with this if the INTENT of SELF in T_PROC was INOUT).

 

For whatever it's worth, 

1) I think the code conforms to the standard.  This is one of those cases where the standard effectively ends up giving programmers enough rope to shoot themselves in the foot.  And so,

2) yes, it is a practice best avoided i.e., to try "write" to derived type components directly and/or as actual arguments to bound procedures with dummy arguments that are not components of the passed-object.  Better to use dedicated "setter" methods that make clear the intent.

3) See 2)

Steve_Lionel
Black Belt Retired Employee
286 Views

I see nothing wrong with this. You are referencing MYVAR%J only through the dummy argument K and not also through some other means. That the procedure is type-bound to the same variable is not relevant. If you also had an assignment to SELF%J, that would be a problem.

OP1
New Contributor I
258 Views

Thanks for the answers. I guess my worry is that, if we had INTENT(INOUT) on line 10, in some circumstances (which existence I am only speculating about) a temporary copy of SELF would be made in T_PROC, and that upon exiting T_PROC the change made to SELF%J would be lost.

Steve_Lionel
Black Belt Retired Employee
233 Views

A compiler that did that would be violating the standard. 

Reply