Let my try to sum up the proposals in this thread: (a) LOGICAL(C_Bool) This is interoperable with C99 _Bool and defined within the standard. (One can argue how well-defined it is, esp. on the C99 side.) (b) Using INTEGER(C_INT) That matches the C version's "int", but requires to use integers for Boolean purposes and is odd with the the non-MPI_F08 version. Both (a) and (b) require special user handling, e.g. instead of ".true." one has to use ".true._c_bool" or (e.g.) "1"/"MPI_TRUE". In addition, they might cause problems with the MPI 3 goal: "In a single application, it must be possible to link together routines which USE mpi_f08, USE mpi, and INCLUDE 'mpif.h'." (page 598, 17.1 Fortran Support) (c) Using LOGICAL without BIND(C) That surely works, but it makes the work for the MPI implementation much harder. Without BIND(C), there is no defined C interface and the implementation has to be compiler specific. Especially for dimension(..) and for passing characters (scalar, array, allocatable/pointer or neither), different compilers will handle them differently. (d) LOGICAL(C_INT) This proposal requires a change of Fortran standard; It effectively matches the current MPI 3 spec. For compilers which implement LOGICAL internally as INTEGER, it is probably fine. However, some compilers don't, e.g. GCC's and NAG's. (1) If one has a different kind value as the normal Fortran LOGICALs, it should work; i.e. kind(.true.) != C_BOOL_INT. But that defies the whole purpose and one could simply use version (a) � or (b). If one demands C_INT == C_BOOL_INT [or the support of LOGICAL(kind=kind(.true.))], I see three possibilities: (2) One is to only allow certain values like 0 or 1. This has two down sides: (a) it either forces the user to use the compiler-specific true/false values or the compiler to use some specified values (0 and 1 instead of 0 and -1), including for existing, non-BIND(C) code! (b) It probably will break sooner or later with user code, which uses different values on the C side. (3) Or one forces the compiler to accept also other values than .true./.false. As with the previous item, it will affect also all non-Bind(C) logicals. And C_Bool should presumably excluded as one otherwise might get in trouble with the C compiler. (4) Last, handling dummy arguments/result variables of BIND(C) procedures differently. That probably would work, but it requires a bunch of the careful addition of additional constraints. For instance, to prohibit the TARGET/POINTER attribute for those. * * * Thus, (a), (b) and (c) require MPI 3 changes. (c) is simple from the MPI spec side but puts the burden on the MPI implementers. And (d) requires changes of the Fortran standard (and possibly simpler changes on the MPI spec side). * Has someone an additional proposal? * Can you give a thump up/down for all the different proposals, allowing a straw vote and helping the MPI forum to decide which way to take? If (d) turns out to be favored, it probably makes sense to at least discuss it on the J3 list before the next meeting of the MPI forum, which is already in 11 days. * * * For me: (a), (c) and (d)(4) are acceptable solutions; I don't like (b) and (d)(1), and I strongly oppose (d)(2) and (d)(3). Tobias