MPI Headers are required to be included in each scope/unit that utilizes MPI procedures, constants, types, etc

[tonyskjellum]

Problem

Apparently, we did not ever formally require headers to be included (mpi.h, etc).
MPI must state that the right language binding (interface) header must be defined in each scope that names MPI procedures constants, types, predefined names (e.g., MPI_COMM_WORLD), return and error codes, etc.

Proposal

While this is clearly the standard's intent since MPI-1.0, it has to be formally stated. Programs that do not do included the headers properly are erroneous. In practice, it is difficult to make such programs, but evidently not impossible

Changes to the Text

We will verify that the text is indeed missing; this appears to be the case. If so, we will add the text formally requiring the right header for each subprogram included in such a way that it is active in the scope or scopes that invoke MPI procedures, functions, types, constants, etc.

This could also be considered an erratum and be added as such to MPI-3 and MPI-3.1.

Impact on Implementations

None.

Impact on Users

Little or none.

References

None

[dholmes-epcc-ed-ac-uk]

Section 2.6.3:

The definition of named constants, function prototypes, and type definitions must be supplied in an include file mpi.h.

Suggestion:

Each compilation unit using C bindings for MPI definitions shall #include this header file.

[tonyskjellum]

@dholmes-epcc-ed-ac-uk -- OK, that is good from the point of view of the implementation's duty. Thank you for this comment.

[mhoemmen]

The C++ Standard already has language that requires includes for correctly declaring C standard library functions. See e.g., [using.linkage]: "Whether a name from the C standard library declared with external linkage has extern "C" or extern "C++" linkage is implementation-defined." That is, there are ways to require including a header file without saying, "You must include a header file."

There are other things like that in C++. For instance, [algorithms.requirements] implies that you can't forward-declare C++ standard algorithms: "The number and order of deducible template parameters for algorithm declarations are unspecified, except where explicitly stated otherwise."

[hjelmn]

@dholmes-epcc-ed-ac-uk /should/must/. I prefer stronger language.

[mhoemmen]

That is, there are ways to require including a header file without saying, "You must include a header file."

This matters because if you mean to address C++, then you'll need to think about the coming of modules, which is a way to get declarations without including a header file.

[hjelmn]

@mhoemmen That won't be relevant until C++ bindings are defined. C++ programs will need to include the C header until then. That is unless WG14 is making the same mistake.

[mhoemmen]

@hjelmn Right, but what you really want to say is not "you must include the header," but "we don't promise that these symbols are macros, functions, or some other thing." Including the header is the way you get the correct declarations right now, but why box yourself in?

[hjelmn]

@mhoemmen Hmm. But don't we already make promises about the symbols? I think from C it is required to ensure that PMPI works as expected.

[mhoemmen]

@hjelmn wrote:

But don't we already make promises about the symbols?

I would say, if the C bindings already say things like "these symbols could be macros or other things," then that implies that a portable MPI C program must include "mpi.h".

[omor1]

@mhoemmen see §2.6.4:

An implementation is allowed to implement MPI_WTIME, PMPI_WTIME, MPI_WTICK, PMPI_WTICK, MPI_AINT_ADD, PMPI_AINT_ADD, MPI_AINT_DIFF, PMPI_AINT_DIFF, and the handle-conversion functions (MPI_Group_f2c, etc.) in Section 17.2.4, and no others, as macros in C.

It's also documented that if these are implemented as macros then they will not work with the MPI profiling interface.

[omor1]

As an aside, someone made the note on a different issue that while MPI is currently specified concretely as a library, a future version could allow implementations to instead see it as a DSL and use a custom compiler. I could see the Adaptive MPI folks being very interested in such an approach, as it could solve the problems they have with global variables in existing programs, among other issues. Such a DSL wouldn't necessarily need to include mpi.h, as the MPI identifiers would be parsed and transformed by the language compiler itself; though it is not a significant burden for the compiler to parse and ignore the include of mpi.h or even to supply an empty header file.

[jeffhammond]

@omor1 If MPI is supported by a magical compiler that consumes all the MPI symbols without a header, then said compiler can deal with the #include <mpi.h> construct as well.

@mhoemmen If/when somebody implements MPI as a C++ module, they can include an empty mpi.h in order to not break existing code. This is not too much to ask.

[mhoemmen]

@jeffhammond wrote:

If/when somebody implements MPI as a C++ module, they can include an empty mpi.h in order to not break existing code. This is not too much to ask.

It could be binding-specific whether the application must include a header file. I'm OK with the C binding requiring an include. It might be redundant, but the MPI Standard isn't too formal anyway. I don't feel too strongly about this.

[jeffhammond]

@mhoemmen We have only one set of bindings for C and C++ right now. If the mpi.h is required for them in general, then we are fine to add this requirement unconditionally. If modules require other changes, then it will be trivial to fix the header inclusion requirement when that happens.

I have no idea how modules work but look forward to your proposal to use them in C++ bindings for MPI 4.1 😄