<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Craig Rasmussen</div><div>CAS Scientific Programmer</div><div><a href="mailto:rasmus@cas.uoregon.edu">rasmus@cas.uoregon.edu</a></div><div><br></div></div></span><br class="Apple-interchange-newline"></span>Ack....
</div><div><br></div><div>I just did a quick rereading of clause 15, Interoperability with C, and it appears ill defined to me. Consider the following:</div><div><br></div><div>1. Suppose a compiler has a default logical size equivalent to a default integer. Since the standard only requires one logical kind, this compiler may not have a type that is interoperable with a _Bool C type. In this instance C_BOOL would be a negative value.</div><div>2. If a compiler does support LOGICAL(kind=C_BOOL), what values of a C type _Bool map to .TRUE.? What values map to .FALSE.? These mappings may be in clause 15 but I didn't see them at first glance.</div><div>3. Suppose a Fortran compiler has the following mapping:</div><div><br></div><div> _Bool flag = 0; /* flag maps to .FALSE. */</div><div><br></div><div> if (flag != 0) ...; /* flag maps to .TRUE. */ </div><div><br></div><div>This seems to me to be the sane way to map values from C to Fortran. The same mapping can be done for any C integer type to an equivalently sized Fortran LOGICAL.</div><div><br></div><div>Also see my specific comments below.</div><div><br></div><div>-craig</div><div><br></div>
<br><div><div>On Feb 28, 2013, at 7:10 AM, Tobias Burnus wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Let my try to sum up the proposals in this thread:<br><br><br>(a) LOGICAL(C_Bool)<br>This is interoperable with C99 _Bool and defined within the standard. (One can argue how well-defined it is, esp. on the C99 side.)<br></div></blockquote><div><br></div><div>May not be interoperable as C_Bool may be negative. Is this even well defined on the Fortran side (see above)?</div><br><blockquote type="cite"><div><br><br>(b) Using INTEGER(C_INT)<br>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.<br></div></blockquote><div><br></div><div>Here at least a programmer can provide something that is well defined and explicitly convert between integer and LOGICAL types.</div><br><blockquote type="cite"><div><br><br>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)<br><br><br>(c) Using LOGICAL without BIND(C)<br>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.<br><br></div></blockquote><div><br></div><div>This may be what MPI is forced to do. MPI provides a Fortran only binding for any interface with a Fortran LOGICAL dummy argument. We have to provide wrappers anyway so this can be done but makes a mess of the interfaces (some bind(C) some not) and makes it much more complex for MPI tool writers.</div><br><blockquote type="cite"><div><br>(d) LOGICAL(C_INT)<br>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.<br></div></blockquote><div><br></div><div>I just tested gfortran and Intel Fortran and they both provide LOGICAL(kind=kind(1)) although gfortran provides a WARNING unless tricked.</div><div><br></div><blockquote type="cite"><div><br>(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).<br><br>If one demands C_INT == C_BOOL_INT [or the support of LOGICAL(kind=kind(.true.))], I see three possibilities:<br><br>(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.<br></div></blockquote><div><br></div><div>What does Fortran do now for C values?</div><br><blockquote type="cite"><div><br>(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.<br></div></blockquote><div><br></div><div>It seems it has to anyway to be compatible with C. I don't have the C99 standard but it appears that there isn't a constant for "true" and "false" without including stdbool.h. Thus a Fortran compiler will have to anticipate values other than .true./.false.</div><br><blockquote type="cite"><div><br>(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.<br><br></div></blockquote><div><br></div>To me this is the only sane response given that C evaluates 0 to false and everything else to true. Nick you want to weigh in on the C standard.<br><div><br></div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>* * *<br><br>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).<br><br>Tobias<br></div></blockquote></div><br></body></html>