[mpiwg-abi] looking for some ABI guidance

Zhou, Hui zhouh at anl.gov
Mon Jan 9 12:22:26 CST 2023


We dived directly into the technical details (intptr_t vs void *).  But first, excuse my ignorance, how do built-in constants, e.g. MPI_INT, work in OpenMPI? In MPICH, those are true constants. And it is a really nice feature that (at least) I appreciate. We can ask users to simply print the handle and deduce a lot of clues on the state of their program. But the appreciation may stem from the fact that I am not a debugger fan. I thought in the proposal of standardizing ABI, we are targeting true compile-time constants, is it correct? Now, if they are compile-time constants, directly casting it as a pointer would be something to frown upon. If we are not directly casting but going through conversions in the compatibility layer, then I don't see the differences from one side (intptr_t) to the other (pointer).
Random question (in the form of bullets, sorry):

  *   If we're talking about standardizing a compatibility layer, and
  *   We're talking about using pointers for MPI handle types, and
  *   Open MPI handles are pointers already, and
  *   Per Hui's description, MPICH integer handles directly correlate to pointers under the covers, then
  *   Why use (u)intptr_t?

I.e., MPICH already uses pointers for the underlying MPI objects, and they're (assumedly) typed.  Hence, it may not be much of a stretch to use typed pointers in the proposed compatibility layer, rather than schlupping everything into a (u)intptr_t.

--

Hui
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mpi-forum.org/mailman/private/mpiwg-abi/attachments/20230109/82aea5a1/attachment.html>


More information about the mpiwg-abi mailing list