[J3] surprisingly PURE

[Steven G. Kargl]

I think we are looking at different docs.  I have n2146.pdf.
C1593 for me starts with

   "In a pure subprogram any designator with a base object that
    is in common or accessed by host..., shall not be used "
    (1) in a variable definition context (19.6.7),

X is available in SUBR via host association.  Y%P = 2.0 is
(indirectly) changing X.

There is then also

  19.5.2.7 Pointer definition status

  The definition status of an associated pointer is that of its
  target.  If a pointer is associated with a definable target, it
  may be defined or become undefined according to the rules for
  a variable (19.6). The definition status

Is Y%P associated with X through default initialization.  X 
is not definable in SUBR via C1593.

-- 
steve 

On Sat, Apr 18, 2020 at 06:31:44PM -0700, Robert Corbett wrote:
> I assume you mean C1594 (1).
> 
> No part of C1594 applies to
> this example.  The variable Y is
> a local variable of SUBR.  The
> variable Y does not satisfy any
> of the conditions listed at the
> start of C1594.
> 
> Robert Corbett
> 
> > On Apr 18, 2020, at 4:38 PM, Steven G. Kargl <kargl at troutmask.apl.washington.edu> wrote:
> > 
> >> On Sat, Apr 18, 2020 at 11:12:27PM +0000, Robert Corbett via J3 wrote:
> >>       REAL, TARGET :: X = 1.0
> >>       TYPE T
> >>         REAL, POINTER :: P => X
> >>       END TYPE T
> >>       CALL SUBR
> >>       PRINT *, X
> >>       CONTAINS
> >>         PURE SUBROUTINE SUBR
> >>           TYPE(T) Y
> >>           Y%P = 2.0
> >>         END SUBROUTINE SUBR
> >>       END
> >> -------------------------------
> >> 
> >> I think the program given above is standard conformant.
> >> If it is not standard conformant, please let me know
> >> why it is not.  I know that it should not be standard
> >> conformant, but I see no reason it is not.
> >> 
> >> The key point here is that default component
> >> initialization does not give the variable the SAVE
> >> attribute.  If Y had the SAVE attribute, the program
> >> would not be conformant.
> >> 
> >> This program is my third attempt to show this problem.
> >> My first program was not conformant, and my second did
> >> not properly demonstrate the problem.
> >> 
> > 
> > Doesn't f2018:C1593(1) apply?  I admit I have troubling reading
> > this section of the Fortran standard. 
> > 
> > -- 
> > Steve
> 

-- 
Steve