A couple of Fortran 2003 C interop problems in Sun Studio 12
This is question for the Sun Fortran compiler team.
I'm trying to compile some code using Sun Studio 12 compilers under both Linux and Solaris Express (5/07) and am encountering errors while compiling some code that g95 accepts and I think is allowed by the standard. The following example illustrates the problem. What I'm trying to do is set up interfaces to a C routine that will accept a Fortran string define in either of two ways; 1. As an interoperable Fortran assumed length string and 2. as an assumed size array of 1 byte characters. I would also like to provide a generic interface name that is the same as the C function I'm calling. Again the following example works under g95. PGI 7.0.5 compiler also works O.K.
Module cfuns
USE ISO_C_BINDING
Implicit NONE
Interface ccharfun
Function ccharfun_s(string) BIND(C, NAME="ccharfun")
USE ISO_C_BINDING
Character(LEN=*) :: string
Integer(C_INT) :: ccharfun_s
End Function ccharfun_s
Function ccharfun_a(string) BIND(C, NAME="ccharfun")
USE ISO_C_BINDING
Character(LEN=1) :: string(*)
Integer(C_INT) :: ccharfun_a
End Function ccharfun_a
End Interface
End Module cfuns
Under both Solaris and LInux I get the following error when I try to compile the above code.
Module cfuns
^
"module_cfuns.f90", Line = 1, Column = 8: ERROR: The compiler has detected errors in module "CFUNS". No module information file will be created for this module.
Function ccharfun_a(string) BIND(C, NAME="ccharfun")
^
"module_cfuns.f90", Line = 10, Column = 12: ERROR: "CCHARFUN_A" has the same associated name as "CCHARFUN_S"
So question: is this a bug in the Sun Studio compiler or is Sun interpreting the standard different from g95 and PGI.
Also, the C_INTPTR_T KIND parameter thats suppose to be in ISO_C_BINDING appears to be missing. The compiler says its not defined when I try to use it under an
IMPLICIT NONE.
Thanks
[2051 byte] By [
cfddoca] at [2007-11-27 10:57:34]
# 2
I think that the F2003 standards left it a bit vague. I came across documents from 1999 that suggested it should be allowed. Maybe there was still not a consensus at the F2003 writing.
I read some more recent stuff on this once. I think that multiple interfaces to the same C function are supposed to be allowed, specifically for cases like the example here. Multiple interfaces are not allowed with Fortran procedures. I think there was originally a lack of consensus what happens with a C-callable Fortran function. Maybe F2008 has more details.
As a work-around, you can make an alias symbol to your C function. The syntax is like this:
void alias_name(void) __attribute__((alias("actual_name")));
This should be in the same source file as the actual function.
# 3
It turns out that there is some question about the legality of having multiple interfaces to the same C function:
NUMBER: F03/0076
TITLE: Scope of Fortran names of procedures with binding labels
KEYWORDS: Interoperability, dummy procedures
DEFECT TYPE:
STATUS: J3 consideration in progress
QUESTION:
Is the following conforming:
module A
interface
subroutine CProc() bind(C,name="AnExternalCProcedure")
end subroutine
end interface
end module
module B
interface
subroutine CSub() bind(C,name="AnExternalCProcedure")
end subroutine
end interface
end module
ANSWER:
The standard's current wording is such that this is not conforming. The
name of an external procedure is a global entity and it is unique to a
given procedure. That is, the external C procedure AnExternalCProcedure,
must be given a unique Fortran name inside a Fortran program.
However, the question is whether this was intended or whether it
happened by virtue of improper integration of binding labels (which
should be global entities, rather than the Fortran name) with the
existing words for Fortran external procedures (which have only one
name, the Fortran name, and therefore it should be global). Forbidding
examples like tone one above violate basic principles of modularity and
introduce global entities without justification. The Fortran names given
to the external C procedure AnExternalCProcedure should be local to the
scopes of modules A and B respectively, not of global scope.
Correcting this problem may be done in the next revision of the
standard, if it is deemed that the answer to this Interp ought to be
yes.
EDITS:
SUBMITTED BY: Aleksandar Donev
HISTORY: 06-107m175 F03/0076 Submitted
igba at 2007-7-29 12:10:00 >
