[J3] surprisingly PURE

Mon Apr 20 01:34:31 EDT 2020

>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 <mailto: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.

-- 
Steve

Disclaimer

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. Please see our  <https://www.nag.co.uk/content/privacy-notice> Privacy Notice for information on how we process personal data and for details of how to stop or limit communications from us.

This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20200420/bf8ee389/attachment-0001.htm>