<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Tobias made a nice summary of character issue. In particular, I'm of the opinion that the Fortran standards body does not think there is a bug in character string interoperability. That was fixed in TS29113 by allowing character strings to be passed by descriptor, depending on the interface description.</div><div><br></div><div>However, the whole issue become moot if we drop the BIND(C) names from the MPI namespace.</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 27, 2013, at 3:44 PM, Tobias Burnus wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>I restrict myself to replying to Option 4, only, in this email.<br><br>Rolf Rabenseifner wrote:<br><blockquote type="cite">Option 4:<br></blockquote><blockquote type="cite">(needed for 2c, for all others it is independent)<br></blockquote><blockquote type="cite">- Substituting in mpi_f08<br></blockquote><blockquote type="cite"> all CHARACTER(LEN=xxx)<br></blockquote><blockquote type="cite"> by CHARACTER(LEN=1),DIMENSION(xxx)<br></blockquote><blockquote type="cite"> with xxx = a fixed constant.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> As far as I understand, this cannot be done for CHARACTER(LEN=*)<br></blockquote><blockquote type="cite"> because otherwise the MPI routine cannot learn about the length<br></blockquote><blockquote type="cite"> of the string, see, e.g., argv array in MPI_COMM_SPAWN.<br></blockquote><br>For C interoperability, "character(len=*)" doesn't make sense as with Bind(C) just a pointer is passed without any length information (and the string is also not zero-terminated). With Fortran semantics, one either passes the length as hidden argument or does not pass the pointer to the data but some descriptor with the length information. In order to make "len=*" work with Bind(C), the information has to be passed in some way.<br><br>However, using<br> subroutine sub(str, len) Bind(C)<br> integer :: len<br> character, dimension(len) :: str<br>would be one valid replacement - albeit slightly inconvenient. (Without BIND(C), character(len=len) is also valid but has no advantage to len=*.)<br><br><blockquote type="cite"> Pro: As far as I understand, this is needed for BIND(C) for the<br></blockquote><blockquote type="cite"> MPI routines that have CHARACTER(LEN=xxx) dummy arguments.<br></blockquote><blockquote type="cite"> Con: Non-consistent solution for a bug in TS29113 that should be<br></blockquote><blockquote type="cite"> fixed in TS29113.<br></blockquote><blockquote type="cite"> The mpi and the mpi_f08 moudlues will be inconsistent to each other. We do not want to change the old mpi module and mpif.h Fortran interface.<br></blockquote><br>Note: For users, both interfaces act exactly in the same way and they shouldn't be able to detect the difference. (Unless their compiler doesn't support that part of Fortran 2003. But (nearly) all current compilers should be able to do so.)<br><br><blockquote type="cite"> With current CHARACTER(LEN=xxx), the MPI routine can check at<br></blockquote><blockquote type="cite"> runtime whether the provided actual argument is long enough.<br></blockquote><blockquote type="cite"> With CHARACTER(LEN=1),DIMENSION(xxx), such a check is impossible.<br></blockquote><br>I fail to see why the diagnostic should be impossible. Compilers are doing array bounds checks since ages. If the explicit interface is known, compilers can simply insert a check before the function call. If the interface is not known, it gets more cumbersome but it is also possible (e.g. some compiler store in the caller the size of the actual arguments in a global variable and compare in the callee the values with the expected sizes).<br><br>The only advantage of len=... is that Fortran semantic implies that the string length of the actual argument is available to the callee, which makes checking simpler. But of one passes a simple "char *" with BIND(C), this information is also not available.<br><br>In addition, if the the array sizes are known at compile time and an explicit interface is used (or, as here, both are in the same file), a compiler can detect the mismatch even at compile time:<br> Warning: Actual argument contains too few elements for dummy argument 'x' (3/5)<br><br>subroutine foo(x)<br> character :: x(5)<br>end<br><br>call foo("abc")<br>end<br><br><br><blockquote type="cite"> Bill and Craig, please correct me if I'm wrong.<br></blockquote><blockquote type="cite"> Is this bug fixable in TS29113, or is there a reason,<br></blockquote><blockquote type="cite"> why CHARACTER(LEN=xxx) is not interoperable with C?<br></blockquote><br>Well, TS29113 cannot be changed as it is not a bug (solvable via an interpretation request) and as the TS is published; it would be rather something for the next Fortran standard.<br><br>At least if one does not allow assumed-length, there is no real fundamental reason to not allow other lengths.<br><br>However, one runs into many inconsistencies and has to deal with a lot of special cases. For instance, while "character(len=1), value" and "char" are passed in the same way, "character(len=2), value" does not match any C type. Assuming, one could use "char[]". But then, passing len=1 by value ("char") and len=2 by reference ("char[]") doesn't look clean. A "character(len=1)" would be "char *" and "character(len=2)" then "char**". But what would be "character(len=n)" - what happens if one changes an "integer :: n = 1" to "integer, paramter :: n=1", would that change the ABI?<br><br>I think there are too many issues like those to make it very unlikely to be changed in the next standard. In particular, as using<br> character(len=1), dimension(xxx) :: str<br>works sufficiently well and it is already implemented in most currently used compilers. Hence, I believe the standard will only be augmented if a very strong case can be made that allowing len=1 has large advantages. (I do not see this happening.)<br><br>Tobias<br></div></blockquote></div><br></body></html>