AtoU on MPI_GET_ADDRESS

[jeffhammond]

Problem

Advice to users. C users may be tempted to avoid the usage of MPI_GET_ADDRESS and rely on the availability of the address operator &. Note, however, that & cast-expression is a pointer, not an address. ISO C does not require that the value of a pointer (or the pointer cast to int) be the absolute address of the object pointed at - although this is commonly the case.

The parenthetical "or the pointer cast to int" is horrible, because int is not capable of holding the address or pointer on the majority of systems now relevant to MPI.

It also seems contrary to C's "The unary & operator yields the address of its operand." This sentence was added in C99 and remains there in C17, which means it is normative pending https://github.com/mpi-forum/mpi-standard/pull/816.

However, C++11 says "The result of the unary & operator is a pointer to its operand." There is a dedicated addressof function that serves the purpose unambiguously. As noted in https://stackoverflow.com/questions/14820307/when-to-use-addressofx-instead-of-x, addressof is only required because C++ allows bad ideas with operator&.

Proposal

Remove the parenthetical. Alternatively, if people really love the concept, then we need to change it to say either (u)intptr_t specifically or "an integer type of sufficient width".

Changes to the Text

Impact on Implementations

Impact on Users

References and Pull Requests

[devreal]

A possible modification to the paranthesis (avoiding int specifically):

(or the pointer cast to an integral type of pointer size)