This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
I deal with mixed-language c/c++/fortran codes and
it appears I might be able to define an inter-language
opaque reference (e.g. a Comm) as C int64t for passing
to fortran and using the MPI_Comm_c2f/f2c macros to encode/decode it on the C side.
The MPI standard says that on the FORTRAN side the object handles are of type INTEGER.
Presumably, then to make sure things are not done accidently, the FORTRAN interface receiving
such an integer from C would declare it INTEGER*8, not default the integer size at the whim of
the FORTRAN compiler.
On the fortran side, one might need to step the int64t down to an int32t (INTEGER*4)
before calling to MPI on some of the compilers I know of today.
My question for the MPI implementation wizards is:
Does anyone know of a current platform where
f90 INTEGER is *bigger* than C int64t/INTEGER*8 (e.g. default
is INTEGER*16, yikes!) or a where misplaced fortran
compiler option might make that true?
Due to an automated code generator in the processing (babel)
I have to pick one of INTEGER*4 or INTEGER*8 and stick to it.
I'm guessing INTEGER*4 would be a poor choice for MPI opaque
objects in calling on some MPI implementations.