[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [mpi-21] ABI (was: Call for MPI 2.2 and 3.0...)

And the way that each MPI does it is a bit different. For example, Open MPI plays some evil games with making SEEK_* be a const int when the C++ bindings are available, which works kindof, as long as the application writer doesn't want to use the SEEK_* constants in a switch statement. Or, like MPICH, Open MPI can just not provide SEEK_* in the C++ bindings.

This does actually cause ABI differences, as Open MPI has now made the plain SEEK_* part of its ABI (since they're now symbols).

Of course, this is one of the areas where I think the standards community could easily rename those constants and not a whole lot of people would complain (since they barely work as it is). And the few that would complain about a standard change here would be far outweighed by the number of people that don't want to have to deal with this corner case of the standard.

Brian

On Dec 6, 2007, at 1:06 PM, William Gropp wrote:

Because this is a significant flaw in the standard, implementations will and do strive to work around it. Of course, any workaround is non-portable because it will be non-compliant. For example, an implementation may have the option to not define these in C++ in case you want to use stdio.h .

Bill

On Dec 6, 2007, at 1:57 PM, Greg Lindahl wrote:

On Thu, Dec 06, 2007 at 11:30:43AM +0100, Dries Kimpe wrote:

One example of compile-time problems is the issue with SEEK_SET, SEEK_CUR,
SEEK_END and the MPI C++ bindings.

Is this a place where MPI implementations are different? Yes, a bug in
the standard, but no, not a source of unportability when moving to a
different MPI implementation.

-- greg



William Gropp
Paul and Cynthia Saylor Professor of Computer Science
University of Illinois Urbana-Champaign



--
  Brian W. Barrett
  Dept. 1422: Scalable Computer Architectures
  Sandia National Laboratories