(j3.2006) INTENT(IN) C_PTR dummy argument of a PURE function

[John Reid]

Bill Long wrote:
>
> On Oct 26, 2015, at 11:02 AM, John Reid <John.Reid at stfc.ac.uk> wrote:
>
>> J3,
>>
>> Here is an issue that J3 has discussed. Was it ever resolved?
>>
>> Is this code standard conforming?
>>
>>      PURE FUNCTION bar_f2c(b) RESULT(p)
>>        USE iso_c_binding
>>        TYPE(c_ptr), intent(in) :: b
>>        TYPE(c_ptr) :: p
>>        p = b
>>      END FUNCTION bar_f2c
>>
>> ifort and gfortran do not fault it, but NAG does because of "Implicit
>> pointer assignment from B?.
>
> Cray and PGI compilers also compile this with no  messages.
>
>>
>> C1283 in 10-007r1 says:
>>
>> In a pure subprogram  ... a dummy argument with the INTENT (IN)
>> attribute, ... shall not be used
>> ...
>> (2) as the data-target in a pointer-assignment-stmt ,
>> ...
>> (4) as the expr of an intrinsic assignment statement in which the
>> variable is of a derived type if the derived type has a pointer
>> component at any level of component selection,
>
> The ?pointer? here is a Fortran pointer.  Certainly C_PTR has no component that even remotely resembles a Fortran pointer.
>
>> ...
>>
>> The above code seems to break the spirit of the above rules but not the
>> letter. I think (4) should read
>>
>> (4) as the expr of an intrinsic assignment statement in which the
>> variable is of a derived type if the derived type is C_PTR, C_FUNPTR,
>> or has a pointer component at any level of component selection,
>
> So, the argument is that someone could create an argument of type C_PTR that is the C address of a variable in the program, reference this function, and then convert the result to a Fortran pointer via C_F_POINTER.   I think this is a bit beyond the idea that the pure function created a pointer association.

All three compilers to which I have access agree that this does not 
conform to the standard:

     PURE FUNCTION barf2c(b) RESULT(p)
       real, pointer, intent(in) :: b
       real, pointer :: p
       p => b
     END FUNCTION barf2c

My point is the p=b in the original code is essentially a pointer 
assignment, so should be disallowed.

The draconian rules for pure procedures are designed to ensure that 
there can be no side effects. Unfortunately, I do not have an example to 
hand showing that pointer assignment can cause a side effect. If I did, 
I think it would be possible to modify it to show the same effect with 
TYPE(c_ptr) objects.

Cheers,

John.