iso_c_binding in ifort - does it conform to the standard?

[jerzyg]

I have been wondering if the current implementation of iso_c_binding in ifort really complies with the Fortran 2003 standard.

Let's consider the following trivial program:

[fortran]program cbinding
use iso_c_binding
implicit none
integer,dimension(3) :: obj  ! <-- 
! Should be:
! integer,dimension(3),target :: obj 
integer,dimension(:),pointer :: fptr

type(C_ptr) :: ptr

obj = 1

ptr = c_loc(obj)
call c_f_pointer(ptr,fptr) ! <--
! Should be:
! call c_f_pointer(ptr,fptr,[3])

fptr(1) = 10
write(*,*) obj

end program
[/fortran]

bindings.f90

Although the code contains two critical errors, it compiles without any warning (/stand:f03 /warn:all included). Obviously, the program crashes at runtime because of memory access violation.  

1) line 4: obj must have "target" attribute. As stated in "ISO/IEC JTC1/SC22/WG5 N1601" (Fortran 2003 standard) document, the argument of c_loc can be an interoperable variable that has "target" attribute (other cases refer to allocatable/pointer entities, but it falls beyond the scope of this post). Since the declaration of obj is available, the compiler could readily detect the problem and report it.

2) line 14: the third parameter (SHAPE) is mandatory in this context and the compiler could easily determine this from the declaration of fptr. Quoting from "ISO/IEC JTC1/SC22/WG5 N1601", page 392:
"SHAPE shall be present if and only if FPTR is an array; its size shall be equal to the rank of FPTR."

The code was compiled with ifort 12.1.5 and 13.0.0.060 - both fail to detect these questionable issues in the code.

Is my understanding of the standard wrong?  Even if it is, wouldn't it be a good idea to add some detections of such violation of good programing practice (and, possibly, Fortran03/08 standards)? It would be extremely handy if the compiler could issue a warning or error message. For instance, gfortran detects both flaws in the example provided.

best regards,
Jerzy

[Steven_L_Intel1]

You're asking the wrong question.  First, the standard describes what a standard-conforming program looks like and does.  It does not specify the behavior for a program that does not conform to the standard.  The standard does require the "processor" (compiler) to be able to detect and report "an additional form or relationship that is not permitted by the numbered syntax rules or constraints, including the deleted features described in Annex B."

There are no numbered syntax rules or constraints in the chapter on C interoperability features, so the compiler is not required to diagnose any violation of the rules there.  I will note, though, that the F2008 standard  relaxed the rule for C_LOC, removing the requirement that the argument be interoperable. 

As for C_F_POINTER, I agree that it would be nice if the compiler could diagnose this, but it is not required to. Our current implementation of ISO_C_BINDING is just a normal Fortran module, the compiler doesn't know that it is special (other than that it is found as an intrinsic module), so certain additional checks are not possible.  We are designing a method which will allow the compiler to know more about intrinsic module procedures and it will be applied, where appropriate, in ISO_C_BINDING.

[jerzyg]

Dear Steve,

thanks for your prompt and precise reply.

I understand that the compiler is not required to check whether the program violates the standard or not. However, for this sort of coding errors it would be very useful if the programmer was be supported by the compiler.

I propose you can possibly add such diagnostics to the "feature request list".

best regards,
Jerzy

[Steven_L_Intel1]

Jerzy,

Yes, I will add that as a feature request.