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

Sat Aug 25 10:29:12 CDT 2012

Okay, we should refer in both directions:

Add additional the sentence after MPI-3.0 Draft 2, page 19 line 16
(MPI-2.2 p18:17):

      The MPI_ prefix reservation is relaxed when the profiling 
      interface is used, see Section 14.2.2 on page 558 for details. 

Same sentence for Fortran after MPI-3.0 Draft 2 p18:42 / MPI-2.2 p17:44. 
For C++, the following is needed after MPI-2.2 p18:41:

      The MPI namespace reservation is relaxed when the profiling 
      interface is used, see Section 14.2.2 on page 558 for details. 

And: 
> > Add a new sentence after MPI-2.2, Chapter 14 "Profiling",
> > Sect. 14.2 "Discussion", page 454, line 17,
> > respectively, after MPI-3.0 Draft 2, Section 14.2 "Profiling",
> > Sect. 14.2.2 "Discussion", page 558, line 34/35:
> >
> >   Typically, the profiling interface is used by implementing
> >   a new application or profiling function that has the same
> >   name as an MPI routine and internally calls the corresponding
> >   PMPI routine; this is an exception to the name prefix
> >   reservation rules in Sections 2.6.2 and 2.6.3 on pages 18 and 19.
> >

Good so?

Rolf

----- Original Message -----
> From: "Bronis R. de Supinski" <bronis at llnl.gov>
> To: "Rolf Rabenseifner" <rabenseifner at hlrs.de>
> Cc: "Martin Schulz" <schulzm at llnl.gov>, "Dave Goodell" <goodell at mcs.anl.gov>, "Kathryn Mohror" <mohror1 at llnl.gov>,
> "Main MPI Forum mailing list" <mpi-forum at lists.mpi-forum.org>
> Sent: Saturday, August 25, 2012 4:39:53 PM
> Subject: Re: [Mpi-forum] Reserved MPI_ prefix & namespace in C and Fortran
> I agree with Bill that the right solution is a forward
> reference at the point the restriction is defined. It
> will be lost if we bury it in the tools chapter.
> 
> On Sat, 25 Aug 2012, Rolf Rabenseifner wrote:
> 
> > Bronis, Martin, Dave, Kathryn, and all tools people,
> >
> > Yes, we should also solve this 2nd inconsistency about
> > defining MPI_Xxxx with real MPI-names when writing a tools layer,
> > which is inconsistent with the prefix reservation in Sect.
> > 2.6.2-2.6.4
> > with the original wording and also with the new wording below.
> >
> > Here, I would propose to relax the prefix reservation defined in
> > Sections 2.6.2 - 2.6.4 by a sentence in the tools chapter
> > that refers to Sect. 2.6.2-2.6.4.
> >
> > Proposed solution (please take it a s a first draft):
> >
> > Add a new sentence after MPI-2.2, Chapter 14 "Profiling",
> > Sect. 14.2 "Discussion", page 454, line 17,
> > respectively, after MPI-3.0 Draft 2, Section 14.2 "Profiling",
> > Sect. 14.2.2 "Discussion", page 558, line 34/35:
> >
> >   Typically, the profiling interface is used by implementing
> >   a new application or profiling function that has the same
> >   name as an MPI routine and internally calls the corresponding
> >   PMPI routine; this is an exception to the name prefix
> >   reservation rules in Sections 2.6.2 and 2.6.3 on pages 18 and 19.
> >
> > Because this is specific to the profiling layer, I would not
> > stress the wording in the Terms chapter. The right position
> > is really the tools chapter.
> >
> > You, as the tools group may find a better wording and fine grained
> > position of this sentence. Important is, that this sentence
> > only solves the existing inconsistency, because this is the scope
> > of this erratum.
> >
> > Okay? Better proposals? Comments?
> >
> > -----------------------------------
> > Here again the latest version of the text 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++
> >>   "Programs must not declare
> >       names (identifiers), e.g., for variables, functions,
> >       constants, types, or macros,
> >>    in the namespace MPI."
> > -----------------------------------
> >
> > Best regards
> > Rolf
> >
> > ----- Original Message -----
> >> From: "Bronis R. de Supinski" <bronis at llnl.gov>
> >> To: "Main MPI Forum mailing list" <mpi-forum at lists.mpi-forum.org>
> >> Sent: Saturday, August 25, 2012 2:34:38 PM
> >> Subject: Re: [Mpi-forum] Reserved MPI_ prefix & namespace in C and
> >> Fortran
> >> So, while we are debating whether the wording is sufficient,
> >> we are overlooking a far more important error in the restriction.
> >> It is simply wrong. The standard is not consistent.
> >>
> >> Specifically, when one uses the MPI profiling interface, the
> >> mechanism is precisely to declare functions that begin with
> >> MPI_. So the intent of the standard is that we are supposed
> >> to violate that restriction. This issue has nagged at me in
> >> the past but I have simply ignored it. However, I would oppose
> >> increasing the scope of the restriction without fixing the
> >> real inconsistency.
> >> _______________________________________________
> >> 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)
> >

-- 
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)