(j3.2006) paper 13-228

[Bill Long]

On 2/5/13 6:45 PM, Malcolm Cohen wrote:
> Bill Long wrote:
>> I'm not convinced the first alternate edit is correct.  If the dummy
>> argument associated with the pointer function reference is never
>> referenced in the procedure, the procedure appears to be still
>> conforming.
>
> Not so.  Any modification to an entity associated with a dummy argument that
> does not have the TARGET or POINTER attribute is required to go through the
> dummy argument.

The entity in question does have the TARGET attribute. But I was just 
pointing out that there are ways to write a standard-conforming program 
that has an actual argument of a pointer function reference, and yet be 
labeled as non-conforming by the wording of the edit.  That's what I 
meant by saying the edit is "not ... correct".

Note that the example for Q1 has two problems.  It appears to violate 
the anti-aliasing rules for dummy arguments.  But also, it violates the 
rules for an INTENT(IN) dummy argument, since execution of the 
subroutine causes the non-pointer INTENT(IN) dummy argument to become 
defined.   In the interp discussion it might be helpful to explain why 
the example code is not conforming.


>> Or if the procedure has only one argument and no other
>> access to data outside the procedure (no USE or COMMON or host
>> association) then the target of the corresponding actual argument
>> pointer could be modified by the procedure and still have a conforming
>> procedure.
>
> You seem to be thinking it is being modified through that dummy argument, which
> was not the intent of my wording "target of the pointer result is modified".  I
> meant that to imply that it was being modified "other than through that dummy
> argument".
>
> I left those words out because I thought it clear enough, this is only
> describing the exception not establishing any requirement, and the paragraph is
> already quite long, ... but if it's causing confusion we can easily put those
> words back in.

The extra words are definitely needed.   I think that fixes the problem 
for the intro part of the standard. (If we opt for the alternate 
answer/edits.)

>
>> I find the prospect of having programs that were perfectly legal in
>> F2003 suddenly breaking to be disconcerting.
>
> Absolutely.
>
>>    It is also disturbing to
>> make codes that are legal now with F2008 suddenly no longer legal.
>
> Regrettable though it is, it is not that infrequent an occurrence.  It usually
> doesn't rise to the level of ripping out a whole feature though.
>
>>    As Bob says, "no good solutions".
>
> Right, we have to pick the "least worst" one.  Opinions may differ as to which
> one that is.
>
> There is a "third way", but I thought it even worse so didn't bother to write it
> up and make edits.  Viz, having a pointer function reference denote a variable
> only where these problems cannot arise.  But that would not only be a horrible
> inconsistency, but one of the prime places for wanting a pointer function
> reference to denote a variable was as an actual argument, so I thought that
> would be even less popular than the other possible solutions...

And yet something that we might consider.  The idea of being able to write

   f(x) = expr

does have its attraction, and compilers have gone to the effort to make 
that work.  I don't have good data on how many user codes employ this.

Cheers,
Bill


>
> Cheers,
>

-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101