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