[J3] [EXTERNAL] Re: surprisingly PURE

[Van Snyder]

I like Malcolm's proposed constraint.
Might there be a problem with type extension and allocating polymorphic
variables?
If a local polymorphic variable is allocated using the dynamic type of
a dummy argument, and the dynamic type has default initalization for a
pointer component and the initialization associates the pointer
component with a verboten variable, one could then change the value of
the pointer component's target by, say, polymorphic assignment.  If
this can happen, I think that preventing it with a constraint would be
at best difficult and at worst impossible.
I hope I'm misaken.
Van
On Mon, 2020-04-20 at 14:34 +0900, Malcolm Cohen via J3 wrote:
> >Y%P is associated with the host-associated variable X.
>  
> That is “pointer associated”. Not any other form of associated.
>  
> > Doesn't C1594 (1) then apply as X cannot appear in variable
> definition context.
>  
> X is not appearing in a variable definition context. “Y%P” is
> appearing in a variable definition context. And Y%P does not satisfy
> the “any designator etc” condition of C1594.
>  
> I note that in a larger example, it might not be at all obvious that
> Y%P remains associated with X by the time of the assignment
> (constraints have to be compile-time-checkable).
> 
> 
> >, it seems odd to me that the Fortran standard would allow a
> variable available through host association in a pure subprogram to
> be indirectly (re)defined by pointer association
>  
> It didn’t use to. This was successfully prohibited in F95 and F2003.
>  
> It is an oversight when, in Fortran 2008, pointer initialisation (to
> non-NULL) was added, without considering this issue.
>  
> It’s easy to see that this is a mistake, considering that the pointer
> assignment
>     Y%P => X
> is prohibited in this context (in a pure subprogram with local Y and
> non-local X), by C1594(3).
>  
> Perhaps the most obvious fix is to disallow a local variable in a
> PURE subprogram from having a data pointer component that is default-
> initialised to a target that is not a local variable of the
> subprogram. That might be too big a hammer, but I don’t think so;
> since the declaration of the local variable effectively does the
> prohibited “Y%P=>X” pointer assignment, it is the declaration that
> should also be prohibited.
>  
> C1589a A nonallocatable nonpointer local variable of a pure
> subprogram, or of a BLOCK construct within a pure subprogram, shall
> not have a default-initialized ultimate component that is a data
> pointer component, if the data pointer component has an initial-data-
> target that is not a local variable of the subprogram.
>  
> I note there is possibly another example, using allocation. Here it
> is the allocation that would be performing the forbidden pointer
> assignment.
>  
> Something like
>  
> MODULE m
>   INTEGER,TARGET :: oops = 0
>   TYPE t
>     INTEGER,POINTER :: ip => oops
>   END TYPE
>   TYPE ct
>     TYPE(t),POINTER ::tp
>   END TYPE
> CONTAINS
>   PURE SUBROUTINE S(n)
>     TYPE(ct) x
>     ALLOCATE(x%tp)
>     x%tp%ip = n
>   END SUBROUTINE
> END MODULE
>  
> Unless I’ve missed something (always possible), this would also
> appear to be valid. And X does not have any default initialization,
> it is X%TP that has default initialization, and that only springs
> into play if X%TP gets allocated.
>  
> One could prohibit this second example by changing “ultimate
> component” in C1589a to “component at any level of component
> selection”. However, that does looks like a hammer that is too big,
> and so since it is the allocation that is doing the bad thing,
> perhaps we should consider a constraint on the allocation instead.
> (Wordsmithing such a constraint left as an exercise to the reader.)
>  
> Cheers,
> -- 
> ..............Malcolm Cohen, NAG Oxford/Tokyo.
>  
> From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Steven G.
> Kargl via J3
> Sent: Monday, April 20, 2020 7:47 AM
> To: General J3 interest list <j3 at mailman.j3-fortran.org>
> Cc: Steven G. Kargl <kargl at troutmask.apl.washington.edu>
> Subject: Re: [J3] surprisingly PURE
>  
> On Sun, Apr 19, 2020 at 08:43:24PM +0000, Bill Long via J3 wrote:
> > 
> > 
> >> On Apr 19, 2020, at 2:16 PM, Steve Lionel via J3 <
> j3 at mailman.j3-fortran.org> wrote:
> >> 
> >> I admit that I am not all that good as a language lawyer, but I
> >> think Steve K has it right.
> >> 
> >> C1594 says (with irrelevant parts removed):
> >> 
> >> In a pure subprogram any designator with a base object that
> >> is in common or accessed by host or use association
> > 
> > The base object is Y which is local to the subprogram. 
> > 
> >> ,... or an object that is storage associated with any such
> >> variable, shall not be used
> >> (1) in a variable definition context (19.6.7),
> > 
> > Defining a pointer IS defining the target of the pointer. X is
> > host associated. Defining y%p is defining X and so it might be
> > already covered. 
> > 
> > Certainly disallowing this case is consistent with the intention
> > that PURE procedures do not modify non-argument-asscoiated
> > variables outside their scope. 
> > 
> 
> I think we're looking for
> 
> 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
> becomes defined or undefined according to the rules for a variable
> (19.6).
> 
> Y%P is associated with the host-associated variable X. Doesn't 
> C1594 (1) then apply as X cannot appear in variable definition
> context.
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20200419/8fa07691/attachment.htm>