J3/14-221 To: J3 From: Nick Maclaren Subject: Request for Interpretation Date: 2014 August 07 ISO/IEC 9899:2011 is referred to as C11 in this paper. ---------------------------------------------------------------------- NUMBER: TBD TITLE: Interoperable procedures KEYWORD: Interoperability, procedure DEFECT TYPE: Erratum STATUS: J3 consideration in progress In all cases, Alf is a Fortran procedure like this: SUBROUTINE Alf (Arg) BIND(C) INTERFACE SUBROUTINE Arg () BIND(C) END SUBROUTINE Arg END INTERFACE CALL Arg END SUBROUTINE Alf QUESTION 1: Does the following C code conform to the Fortran standard's requirements on interoperability? extern void Bert (void) { ; } int main (void) { alf(Bert); } QUESTION 2: Does the following C code conform to the Fortran standard's requirements on interoperability? static void Fred (void) { ; } int main (void) { alf(Fred); } QUESTION 3: Does the following C code conform to the Fortran standard's requirements on interoperability? extern inline void arg (void) { ; } int main (void) { alf(Joe); } DISCUSSION: In question 1, 15.5.1p2 states that a procedure is defined by means other than Fortran shall have the same binding label as the interface. Function Bert() has a binding label of 'Bert', but 15.5.2p2 states that the argument has no binding label. In question 2, 15.5.1p2 states that a procedure is defined by means other than Fortran shall have a name that has external linkage as defined by 6.2.2 of ISO/IEC 9899:2011. Function Fred() has no such name, as its definition has internal linkage. However, linkage in C affects only the visibility of the external name, and has no application to either types or values, whether in the form of function parameters or other pointers. In question 3, C11 6.7.4 describes the inline specifier. Note that it does not prevent it from having external linkage (see paragraph 7), but there are complicated rules about what is allowed and whether two references to the same external function have the same effect. I cannot explain the implications of that specification, because I do not understand them; indeed, none of the BSI C panel did, and the UK objected to the inline specifier on those grounds. One aspect where there was no consensus in WG14 was under what circumstances (if any) inline functions were required to use the same interface mechanisms as ordinary functions. Also, C interfaces can be used to connect Fortran and C++ (via C++'s defined C interface), and C++'s form of inline is subtly different from C's; it is unclear whether that is allowed. This situation makes no sense in Fortran terms, and I think that it was an oversight not to exclude inline in 15.5.1. ANSWERS: Q1. The code is intended to be conforming. An edit is provided to correct the oversight. Q2. The code is intended to be conforming. An edit is provided to correct the oversight. Q3. The code is not intended to be conforming. An edit is provided to correct the oversight. EDITS to 10-007r1: 15.5.1p2 replace the paragraph by: "If the procedure is defined by means other than Fortran, it shall be describable by a C prototype that is interoperable with the interface. It shall not be an inline function as defined by 6.7.4 of ISO/IEC 9899:2011. If the procedure is defined by means other than Fortran and is accessed using its binding label, it shall also * have a name that has external linkage as defined by 6.2.2 of ISO/IEC 9899:2011, * have the same binding label as the interface. SUBMITTED BY: Nick Maclaren. HISTORY: