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

[Bill Long]

On Oct 26, 2015, at 2:58 PM, John Reid <John.Reid at stfc.ac.uk> wrote:

> 
> 
> 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

Right.  That is what the standard specifically disallows. 

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

To be consistent with that argument, it would seem that C_LOC( ) should not be a PURE function, since it has the effect of associating a C address ( ?pointer? ) with a target.   However, the approved F2015 feature US-22  specifically states that C_LOC is a PURE function.   In order to cause havoc within a Fortran program you have to do something that is not PURE, i.e. call C_F_POINTER (which is singled out as being impure).   

Cheers,
Bill

> 
> Cheers,
> 
> John.
> 
> 
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

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