- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
4 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Good question - I don't know and can't think of a reason. I'll ask the developer who wrote this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is fixed in Update 4.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page