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

Bronis R. de Supinski bronis at llnl.gov
Sat Aug 25 09:39:53 CDT 2012


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



More information about the mpi-forum mailing list