This is the mail archive of the mailing list for the GNU Fortran project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Constraints on variables in pure procedures

(I was clearing out old unanswered stuff, and came across this post from a while ago. The situation hasn't changed, though, so it seems still relevant.)

THOMAS Paul Richard 169137 wrote on 2006/03/03:
If I have understood things correctly, the intention of the constraints
on variables within pure procedures is to:

(i) Prevent a pure procedure to change the value of global variables,
dummy arguments with INTENT(IN), or no declared intent, and objects that
are associated with any part of a global variable; and to
(ii) Prevent the procedure from making pointers to such variables.

Thus, I do not understand the following and cannot find any reference to
it in the standard:

$ cat pr20863a.f90
PURE FUNCTION give_next(i)
     TYPE node_type
       TYPE(node_type), POINTER :: next
     TYPE(node_type), POINTER :: node
     TYPE(node_type), target  :: t
     integer, intent(in)      :: i
     node%next = t

THOMASP@PC-THOMAS-P /cygdrive/d/svn/prs
$ /irun/bin/gfortran -c pr20863a.f90
 In file pr20863a.f90:9

     node%next = t
Error: Right side of assignment at (1) is a derived type containing a
POINTER in a PURE procedure

According to my reading of section 12.6 of the F95 standard, this error is indeed incorrect; this is legal code. The constraint at the bottom of page 212 lists a number of things that cannot be used as "the expr of an assignment-stmt in which the variable is of a derived type if the derived type has a pointer component...." The list includes variables in common or accessed by host or use association, dummy arguments to pure functions, dummy INTENT(IN) arguments to pure subroutines, or objects storage associated with such variables. This is quite definitely not an exhaustive list of all possible variable types, and local variables are not on it.

Further, it is quite implausible that there should elsewhere be a limitation that would make this illegal for local variables, and would not make that entire clause of 12.6 redundant.

If t were a dummy argument, this would be correct would it not?

The presence of an error would be correct, yes. However, if give_next were a subroutine rather than a function, and if t were declared INTENT(INOUT) or INTENT(OUT), then the code would again be legal.

Has a PR been filed for this?

- Brooks

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]