[mpiwg-abi] Tuesday (20 February 2023) meeting agenda

[Jeff Hammond]

For the meeting tomorrow, I would like you all to consider the following:

There is consensus regarding the following to get type safety:
typedef struct MPI_ABI_Handle * MPI_Handle;

We have two choices for predefined handles:

Option 1:
#define MPI_INT (MPI_Datatype)0x3

Option 2:
#define MPI_INT (MPI_Datatype)&MPI_ABI_INT

Option 1 relies on implementation defined behavior regarding the casting of
integers to pointers, but it is safe.  Gonzalo and I had a long discussion
of this, and the only issue is that (intptr_t)MPI_INT == 0x3 is not
guaranteed to be true, but (intptr_t)MPI_INT == (intptr_t)(void*)0x3 is.
Both MPICH and Open-MPI already rely on this technique for MPI_IN_PLACE,
among others.

The advantage of Option 1 - assuming we use a sensible set of
integer values - is that ABI compatibility layers can do translation via a
table.  This is most useful for datatypes, where there are ~100 predefined
handles, and to a lesser extent ops.  For all other handles, there are no
more than 3 predefined handles (IIRC).

Option 2 allows run-time resolution of predefined handles, which I thought
was good until I implemented it in https://github.com/jeffhammond/mukautuva.
While it works and means I can avoid predefined handle translations in the
forward direction, I still have it in the backwards direction, and it's not
exactly simple to resolve all the symbols.  I think Hui also implemented
this in his compatibility layer, although I don't know if he hates it as
much as I do.

The second question is whether to #define MPI_HANDLE_NULL (MPI_Handle*)0.
Lisandro argues for this, and it would make a lot of things easy.

I hope that we can decide these two questions today.  For the second
meeting, we will address predefined integer constants.

Jeff

-- 
Jeff Hammond
jeff.science at gmail.com
http://jeffhammond.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-abi/attachments/20230220/b43218b9/attachment.html>