On Aug 24 2012, Jeremiah Willcock wrote:
What about wording to the effect of 'the name "MPI" and names beginning with "MPI_" are reserved to the MPI implementation, and names beginning with "PMPI_" are reserved to the MPI implementation when used as global-scope function names'; that suggests that they are reserved for all purposes (and thus can be used as macro names by the implementation, etc.)? That also avoids needing to enumerate all of the cases (and there are a few missing on any of the lists we've been looking at so far) and looks more like the kind of wording that is in the language standards.
I was copying the wording in the standards fairly closely; both Fortran and C use the term 'entity' to mean 'more or less anything you can declare'. Using the terminology "reserved to the MPI implementation" rather than forbidding their declaration would work equally well. However, the term 'global-scope function names' will NOT fly, as it makes little sense in either C or Fortran and doesn't cover external variables (in C) or half a dozen classes of external name in Fortran, including COMMON blocks, modules and BIND(C) variables in modules. Also, in Fortran, functions are only one of three classes of procedure.
You might want to also reserve "_MPI" for all purposes as well (even though that name is intended to be reserved to the compiler, not a library) because of the suggestion in the past that some preprocessor symbol be defined when compiling with MPI so that applications can detect it; _MPI follows the same pattern as _OMP and already seems to be used by some applications.
Grrk. Please don't use OpenMP as a model - the MPI standard is of MUCH higher quality, and doesn't conflict with the language standards more than it has to. You could do so, but it makes little sense. Any program that uses the name _MPI in either C or Fortran is already non-conforming (i.e. illegal) and Fortran REQUIRES it to be flagged as erroneous by the compiler. You could request compiler implementors not to use the name _MPI for other purposes, but that's about as far as you can go while remaining in touch with ppracticality. Regards, Nick Maclaren.