[Boost-mpi] Boost::mpi status error() uninitialized on non-blocking request from irecv

[Frederik Heber]

Hey there,

The documentation of boost::mpi says the following about the mpi::status
object returned from a wait_all(..) on a prior stash of irecv()s, i.e.
non-blocking receives (version 1.55, taken from boost/mpi/status.hpp, did

This structure contains status information about messages that
communicator::iprobe). It permits access to the source of the
message, message tag, error code (rarely used), or the number of
elements that have been transmitted.

Hence, calling error() should give me the error_code returned by MPI_Irecv.
However, this "rarely used" is a strange formulation ...

Thus, we take the example contained in the tutorial on non-blocking
communication, modify it slightly to store the resulting status objects,
and inspect their error() return values.

#include <boost/mpi.hpp>
#include <iostream>
#include <string>
#include <boost/serialization/string.hpp>
#include <boost/mpi.hpp>
namespace mpi = boost::mpi;

int main()
{
mpi::environment env;
mpi::communicator world;

if (world.rank() == 0) {
mpi::request reqs[2];
std::string msg, out_msg = "Hello";
reqs[0] = world.isend(1, 0, out_msg);
reqs[1] = world.irecv(1, 1, msg);
mpi::wait_all(reqs, reqs + 2);
std::cout << msg << "!" << std::endl;
} else {
mpi::request reqs[2];
std::string msg, out_msg = "world";
reqs[0] = world.isend(0, 1, out_msg);
reqs[1] = world.irecv(0, 0, msg);
std::vector<mpi::status> status;
mpi::wait_all(reqs, reqs + 2, std::back_inserter(status));
std::cout << "error code: send - " << status[0].error() << ",
receive - "
<< status[1].error() << std::endl;
std::cout << msg << ", ";
}

return 0;
}

The result then is

error code: send - 0, receive - 331828272
world!

I.e. the error code of isend's status is fine, while the one of irecv's
status just shows a probably uninitialized value.

I know that boost::mpi internally checks the return code from MPI via its
macro BOOST_MPI_CHECK_RESULT and it would throw an exception in case of an
error. However, this can be switched off via BOOST_NO_EXCEPTIONS.
Therefore, I would feel better if I were able to check that what I just
received is really ok.

Is this a bug (at least in the documentation) or am I missing something
here?

Kind regards,

Frederik Heber