[Mpi-forum] Preprocessor Constants

[Hal Finkel]

On Fri, 2010-11-19 at 08:57 +0000, N.M. Maclaren wrote:
> On Nov 18 2010, Hal Finkel wrote:
> >
> >Appendix A of the current MPI 3 draft (line 45 of page 545) indicates
> >that MPI_VERSION and MPI_SUBVERSION are of type, "const int (or unnamed
> >enum)". This text is identical to that of the the MPI 2.2 specfication
> >(line 45 of page 523), and it should be changed. As the heading on the
> >previous line implies, these should be "preprocessor constants," and
> >must not be "const int (or unnamed enum)". I recommend replacing, "const
> >int (or unnamed enum)" with "integer literal."
> 
> I don't, but I agree that the existing wording is wrong for the reasons
> you say.  The word 'literal' is used in C99 only for string and compound
> literals.  What you mean is called an integer constant - which, as you
> imply, also has other meanings!  The term that is closest is "integer
> constant token", but the wording used in limits.h is (with integer added
> for clarity):
> 
>     Integer constant expressions suitable for use in #if preprocessing
>     directives.
> 

I'd be fine with "integer-constant token", but I think it is better to
adhere to the "say what you mean" philosophy, so I prefer your suggested
wording.

> >Also, regarding the recommendation I made at the SC'10 BOF, I recommend
> >adding the following text after line 19 of page 18 and after line 43 on
> >page 18:
> >User code may assume that mpi.h is unavailable to the preprocessor
> >unless the preprocessor constant _MPI is defined prior to source-file
> >processing.
> 
> With one reading of the C standard, that breaks conformance; with another,
> it is recommended practice.
> 

I'm not sure what you mean by "breaks conformance." It does cross the
line from purely specifying a library interface to specifying a
compilation environment; _MPI may fall into the namespace reserved for
the implementation (if that alone is a problem, we could choose MPI or
__MPI, etc., but I feel the reserved namespace is appropriate here).

It may be recommended practice, but, if I understand your comment, it is
not uniform, and I feel it would be useful for the standard to provide
some specific guidance. The C standard may not require a mechanism for
predefining macros, but I've never seen any implementation which did not
(and POSIX requires -D for cc/c89/c99 (depending on the version)).

For example, a project on which I've worked combines code from many
different authors and has, in the top-level makefile:
MPICFLAGS = ... -DMPI -DHAVE_MPI -DUSE_MPI ... (and one of the config
headers defines HAVE_MPI_H)
and I think this is silly. mpicc should just add -D_MPI (or similar),
and that kind of makefile clutter could go away. Updating the wrapper
scripts and/or documentation and the codes would be trivial. In
addition, no existing code would have to change (that's why I choose the
wording "may assume" in my suggestion).

Sincerely,
Hal

> Regards,
> Nick Maclaren.
> 
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum