[Mpi-forum] Reserved MPI_ prefix & namespace in C and Fortran

Rolf Rabenseifner rabenseifner at hlrs.de
Sun Aug 26 10:19:16 CDT 2012


Bill, you ask for two things (here the Fortran text, but C is the same):

> Programs must not declare 
> variables, parameters, or functions with names 
> beginning with the prefix MPI_.
> To avoid conflicting with the profiling interface, programs 
> should also avoid functions with the prefix PMPI_. 

The first sentence, we substituted already by
> Programs must not declare
  names, e.g., for variables, subroutines, functions,
  parameters, derived types, abstract interfaces, or modules,
> beginning with the prefix MPI_.

You ask in the second sentence for 
1. Substitute "should" by "must" in the last line
2. Substitute "functions" by "name".

About 1.: Yes, agreed. Always must and should are used as
synonyms in the scope of standards. To use the same
words in both sentences is clarifying that there is
no relevant difference in the meaning.

About 2.: I do not see that it is needed,
i.e., that there is an inconsistency,
and the MPI-1 Forum decided to make a clear difference
between MPI 
 - where all names must be restricted,
 - as we now do,
and PMPI
 - where conflicts are only for routines because we
   do not have any PMPI name for other areas.

Therefore for me, the 2. topic would be out of the scope 
of this erratum.
And I want to keep it as an erratum, because it should
be done before we vote on MPI-3.0 and therefore automatically
included in MPI-3.0.

Okay?

Rolf


----- Original Message -----
> From: "William Gropp" <wgropp at illinois.edu>
> To: "Main MPI Forum mailing list" <mpi-forum at lists.mpi-forum.org>
> Sent: Sunday, August 26, 2012 4:28:22 PM
> Subject: Re: [Mpi-forum] Reserved MPI_ prefix & namespace in C and Fortran
> I would use "must" instead of "should", esp in reference to the PMPI
> interface. I'd also reserve all PMPI and MPI names, not just the
> function/subroutines for PMPI. The intent was always that users avoid
> these two prefixes for any use; anyone who used them was courting
> trouble.
> 
> Bill
> 
> William Gropp
> Director, Parallel Computing Institute
> Deputy Director for Research
> Institute for Advanced Computing Applications and Technologies
> Paul and Cynthia Saylor Professor of Computer Science
> University of Illinois Urbana-Champaign
> 
> 
> 
> On Aug 26, 2012, at 9:03 AM, Rolf Rabenseifner wrote:
> 
> > I updated the ticket 343 with the now hopefully final text
> > for the terms chapter
> > (after Bronis has moved the tools aspect to MPI-next),
> > see
> > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/343
> > and the attached files.
> >
> > I hope that now all can agree with this correction of the
> > existing inconsisteny as detected in the public review
> > and discussed in the previous emails.
> >
> > --------------------------------
> > Latest summary of the necessary MPI-2.2 erratum
> > in Sections 2.6.2 - 2.6.4:
> >
> > C:
> >> "Programs must not declare
> >      names (identifiers), e.g., for variables, functions,
> >      constants, types, or macros,
> >>  beginning with the prefix MPI_."
> >
> > Fortran:
> >> "Programs must not declare
> >      names, e.g., for variables, subroutines, functions,
> >      parameters, derived types, abstract interfaces, or modules,
> >>  beginning with the prefix MPI_.
> >
> > and for Fortran also "subroutines and functions" instead of
> > only "functions" in the sentence about PMPI_.
> >
> > C++ (not visible in MPI-3.0 due to removal of C++):
> >> "Programs must not declare
> >      names (identifiers), e.g., for variables, functions,
> >      constants, types, or macros,
> >>  in the namespace MPI."
> >
> > And change-log entry
> >
> >   Sections 2.6.2 and 2.6.3 on pages 18 and 19, and
> >   MPI-2.2, Section 2.6.2 on page 17, lines 41-42,
> >   Section 2.6.3 on page 18, lines 15-16, and
> >   Section 2.6.4 on page 18, lines 40-41.
> >   This is an MPI-2 erratum: The scope for the reserved prefix MPI_
> >   and the C++ namespace MPI was extended to any name.
> > -------------------------------
> >
> > Best regards
> > Rolf
> >
> >
> > ----- Original Message -----
> >> On Sun, 26 Aug 2012, Bronis R. de Supinski wrote:
> >>
> >> I think we should defer the issue to MPI Next.
> >>
> >> On Sun, 26 Aug 2012, Rolf Rabenseifner wrote:
> >>
> >>> Hello Bronis, Kathryn, Dave,
> >>>
> >>> Do you agree with Martin's opinion and his suggested addition
> >>> for the tools chapter?
> > ...
> >
> > --
> > Dr. Rolf Rabenseifner . . . . . . . . . .. email
> > rabenseifner at hlrs.de
> > High Performance Computing Center (HLRS) . phone
> > ++49(0)711/685-65530
> > University of Stuttgart . . . . . . . . .. fax ++49(0)711 /
> > 685-65832
> > Head of Dpmt Parallel Computing . . .
> > www.hlrs.de/people/rabenseifner
> > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)
> > _______________________________________________
> > mpi-forum mailing list
> > mpi-forum at lists.mpi-forum.org
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> 
> 
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

-- 
Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at hlrs.de
High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)



More information about the mpi-forum mailing list