(j3.2006) (SC22WG5.5369) Question on PURE subroutines
Van Snyder
Van.Snyder
Thu Dec 4 16:57:16 EST 2014
On Thu, 2014-12-04 at 21:45 +0000, Bill Long wrote:
> On Dec 4, 2014, at 2:03 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
>
> > On Thu, 2014-12-04 at 16:55 +0000, Bader, Reinhold wrote:
> >> Hello all,
> >>
> >>
> >>
> >> consider the program
> >>
> >>
> >>
> >> module mod_proc_cont_01
> >>
> >> implicit none
> >>
> >> type :: cont
> >>
> >> real, pointer :: p(:) => null()
> >>
> >> end type cont
> >>
> >> real, target :: p(2)
> >>
> >> contains
> >>
> >> pure subroutine pf(x)
> >>
> >> type(cont), intent(inout) :: x
> >>
> >> integer :: i
> >>
> >>
> >>
> >> if (associated(x%p)) then
> >>
> >> x%p = [ (real(2*i), i=1, size(x%p)) ]
> >>
> >> end if
> >>
> >> end subroutine pf
> >>
> >> end module mod_proc_cont_01
> >>
> >> program proc_cont_01
> >>
> >> use mod_proc_cont_01
> >>
> >> implicit none
> >>
> >> type(cont) :: xx
> >>
> >>
> >>
> >> p = [ 1.0, 2.0 ]
> >>
> >> xx%p => p
> >>
> >> call pf(xx)
> >>
> >> write(*,*) p
> >>
> >> end program proc_cont_01
> >>
> >>
> >>
> >>
> >>
> >> It appears to conform to the Fortran 2008 standard; it is accepted by
> >> the compilers available to me. Yet it
> >>
> >> appears to implement a side effect in a PURE procedure. Was this
> >> intended? If not, would adding the following
> >>
> >> text in 007 fix the problem?
> >>
> >>
> >>
> >> [312:30] After "any designator", add " with the POINTER attribute or "
> >
> > Assuming this is in the first line of C1283 in F08, it goes a bit too
> > far. It effectively prevents meaningful use of pointers within pure
> > procedures.
> >
> > For example, if you have several local variables upon which the code
> > needs to act in several places, instead of repeating the test throughout
> > the code, do the test once and associate a pointer with the necessary
> > variable. The proposed change to C1283 would make it impossible to
> > assign a value using that pointer.
>
>
> The issue that Reinhold points out is the case of a pointer appearing
> in a variable definition context when its target is not a local
> variable, but one that is declared in the specification part of a
> module. We prohibit direct definition of such a variable in a pure
> procedure, so to seems reasonable to also prohibit definition of a
> pointer associated with such a variable.
We constrain against direct assignment to such a variable in a pure
procedure, but not against indirect assignment, for example, if a dummy
argument is a pointer. Reinhold's example is no different from one
where the pointer is the dummy argument, not a component of the dummy
argument.
There are in fact no nonconstraint prohibitions involving what can be
done within pure procedures. We cannot constrain against what Reinhold
wants to prohibit without crippling the use of pointers within pure
procedures.
Prohibiting this behavior other than by constraint would be a new thing.
>
> Cheers,
> Bill
>
>
>
> >
> > I'm not convinced this is an undesirable side effect, but if it is, a
> > much more elaborate prohibition would be needed, to prevent a pointer
> > component of a dummy argument from appearing in a variable definition
> > context or as the data target in a pointer assignment statement.
> >
> >> Cheers
> >>
> >> Reinhold
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> J3 mailing list
> >> J3 at mailman.j3-fortran.org
> >> http://mailman.j3-fortran.org/mailman/listinfo/j3
> >
> >
> > _______________________________________________
> > J3 mailing list
> > J3 at mailman.j3-fortran.org
> > http://mailman.j3-fortran.org/mailman/listinfo/j3
>
> Bill Long longb at cray.com
> Fortran Technical Suport & voice: 651-605-9024
> Bioinformatics Software Development fax: 651-605-9142
> Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
>
>
More information about the J3
mailing list