<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>I talked with Bill briefly on the phone and he suggested something close to what we already do, namely use overloading to get around the problem (see Bill's earlier comment on two levels of wrappers).</div><div><br></div><div>We could switch to LOGICAL(C_BOOL) dummy arguments in all procedures with BIND(C) interfaces. Then in addition we could overload these functions (like MPI_Test) with thin wrappers that are required to call the regular BIND(C) version so that the tools folks are happy. Regular users would never know the difference. I suppose we could actually use INTEGER(C_INT) in these interfaces rather than LOGICAL(C_BOOL) as there is less chance of confusion and INTEGER(C_INT) and LOGICAL can always different. Whereas LOGICAL(C_BOOL) and LOGICAL may be the same type.</div><div><br></div><div>Bill also suggested that replacing LOGICAL dummy arguments with INTEGER(C_INT) in the callback routines would a safer way to go.</div><br><div apple-content-edited="true">
<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><br class="Apple-interchange-newline">
</div>
<br><div><div>On Mar 4, 2013, at 12:19 PM, Bill Long wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br><br>On 3/4/13 1:26 PM, Tobias Burnus wrote:<br><blockquote type="cite">Bill Long wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">There isn't any difficulty about a Fortran wrapper using integers (as<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">C does), and converting them to LOGICAL, but it can't be BIND(C).<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">There is also no difficulty in having the wrapper arguments being<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">LOGICAL.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">subroutine sub (x) bind(c, name="MPI_xxx_f")<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">logical :: x<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">integer(int) :: cx<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">cx = merge(1, 0, x)<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Well, except that compilers might simply reject a default-kind LOGICAL<br></blockquote><blockquote type="cite">with BIND(C), in line with the Fortran standard.<br></blockquote><br>Ug. I tried 5 compilers. Three (Cray, Intel, PGI) just let it pass. One gave an error, and one gave a warning. What a mess. I'm more convinced now that before that the only practical solution here is to get rid of the LOGICAL arguments, replacing them with INTEGER arguments, which is what the C functions expect anyway. (Alternatively, the problem goes away if support for mpif.h is removed, which I would highly recommend anyway.)<br><br>I'm trying to work out how to use two layers of wrapper functions to get around the error from that one compiler. Unattractive, to say the least.<br><br>Cheers,<br>Bill<br><br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">Your code above assumes that a Fortran compiler allows passing a<br></blockquote><blockquote type="cite">default-kind LOGICAL to a Bind(C) procedure and that it then can handle<br></blockquote><blockquote type="cite">that LOGICAL. I think no one really doubts the second part. But the<br></blockquote><blockquote type="cite">first part is not really covered by the Fortran standard and<br></blockquote><blockquote type="cite">standard-conforming compilers do exist, which reject default-kind LOGICALs.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">J3/WG5 could change the standard such that it supports other LOGICAL<br></blockquote><blockquote type="cite">kinds besides C_Bool, including kind(.true.). However, if<br></blockquote><blockquote type="cite">LOGICAL(kind=kind(.true.) / C_INT) exists, users will assume that it<br></blockquote><blockquote type="cite">acts like C's "int", which will lead to problems. So far, I haven't seen<br></blockquote><blockquote type="cite">a convincing proposal how to solve this.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Tobias<br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">mpi3-fortran mailing list<br></blockquote><blockquote type="cite"><a href="mailto:mpi3-fortran@lists.mpi-forum.org">mpi3-fortran@lists.mpi-forum.org</a><br></blockquote><blockquote type="cite"><a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran</a><br></blockquote><br>-- <br>Bill Long <a href="mailto:longb@cray.com">longb@cray.com</a><br>Fortran Technical Support & voice: 651-605-9024<br>Bioinformatics Software Development fax: 651-605-9142<br>Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101<br><br><br>_______________________________________________<br>mpi3-fortran mailing list<br><a href="mailto:mpi3-fortran@lists.mpi-forum.org">mpi3-fortran@lists.mpi-forum.org</a><br>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran<br></div></blockquote></div><br></body></html>