Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

No argument checking on C_F_POINTER

Jugoslav_Dujic
Valued Contributor II
429 Views
My colleague has been bitten by the following code (paraphrasing)

[fortran]type base
...
type, extends(base):: ext
...

type(base), target:: b
type(ext), pointer:: ex
...
call C_F_POINTER(b, ex) !"C" style cast[/fortran]
That compiled (!) and gave a wrong answer (undefined location for ex), because the last line should have been:
[fortran]call C_F_POINTER(C_LOC(b), ex) !"C" style cast[/fortran]
The trail leads to C:\\Program Files (x86)\\Intel\\ComposerXE-2011\\compiler\\include\\iso_c_binding.f90:
[fortran]    ! ---------------------------------------------------------------------
    ! Associates a scalar pointer with the target of a C pointer.
    ! ---------------------------------------------------------------------
    SUBROUTINE c_f_pointer_scalar (cptr, fptr)
!DEC$ ATTRIBUTES DEFAULT :: c_f_pointer_scalar
!DEC$ ATTRIBUTES NO_ARG_CHECK :: cptr, fptr
[/fortran]
Why !DEC$ ATTRIBUTES NO_ARG_CHECK :: cptr? Is it on purpose or by ommission? I don't see why anything other than a C_PTR could legitimately fit here.
0 Kudos
4 Replies
Steven_L_Intel1
Employee
429 Views
Good question - I don't know and can't think of a reason. I'll ask the developer who wrote this.
0 Kudos
Steven_L_Intel1
Employee
429 Views
The NO_ARG_CHECK there is required to make that particular implementation of C_F_POINTER for scalars work, since it relies on knowing that in our implementation scalar pointers are just addresses. In hindsight, another solution would be preferable and I'm testing out an idea on that. C_F_POINTER for arrays doesn't have this problem, but C_F_PROCPOINTER does.
0 Kudos
Steven_L_Intel1
Employee
429 Views
Ok, I have a fix for this that doesn't break compatibility with old code. Amusingly, while I was working on this, I discovered that certain routines in ISO_C_BINDING, such as C_F_POINTER for arrays, do not protect themselves against the caller being built with STDCALL or CVF conventions, potentially causing a stack memory leak. I supplied the fix for that too and escalated it as issue DPD200164533. Thanks for bringing this to our attention.
0 Kudos
Steven_L_Intel1
Employee
429 Views
This is fixed in Update 4.
0 Kudos
Reply