Skip to content

#682 Minor bug in use of shared_ptr<> in mpicollectivecommunicationhh

Metadata

Property Value
Reported by Atgeirr Flø Rasmussen (atgeirr@sintef.no)
Reported at Dec 4, 2009 20:30
Type Bug Report
Version Git (pre2.4) [autotools]
Operating System Unspecified / All
Last edited by Oliver Sander (oliver.sander@tu-dresden.de)
Last edited at Dec 7, 2009 10:28
Closed by Oliver Sander (oliver.sander@tu-dresden.de)
Closed at Dec 7, 2009 10:28
Closed in version Unknown
Resolution Implemented
Comment In dune-common 5750.

Description

There is a bug in the use of shared_ptr<>::operator->(). It attempts to use the operator to extract the underlying pointer, which is then checked. This fails because operator->() will not allow this (treats as an attempt to dereference a null pointer). A simpler check for null-pointerness is !ptr (using the conversion to unspecified-bool-type).

Also, one should use get() instead of operator->() to return the underlying pointer in other contexts (I have not made this change below, though).

Suggested fix:

--- dune/common/mpicollectivecommunication.hh (revision 5741) +++ dune/common/mpicollectivecommunication.hh (working copy) @@ -31,7 +31,7 @@ public: static MPI_Datatype get () {

  • if (type.operator->()==0)
  • if (!type)
      {
        type = shared_ptr<MPI_Datatype>(new MPI_Datatype);
        MPI_Type_contiguous(sizeof(T),MPI_BYTE,type.operator->());

@@ -85,7 +85,7 @@ public: static MPI_Op get () {

  • if (op.operator->()==0)
  • if (!op)
      {
        op = shared_ptr<MPI_Op>(new MPI_Op);
        MPI_Op_create((void (*)(void*, void*, int*, MPI_Datatype*))&operation,true,op.operator->());