X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 09 Dec 1999 15:06:58 -0600 To: mpi-core@XXXXXXXXXXX From: William Gropp Subject: Fwd: Re: MPI_GET_PROCESSOR_NAME \0 or not? X-MIME-Autoconverted: from quoted-printable to 8bit by mcs.anl.gov id PAA68016 Sender: owner-mpi-core@XXXXXXXXXXX The following question has come up. I agree with the questioner; the '\0' shouldn't be written in the Fortran version because it is not part of the name, and resultlen is not described as specifying the valid part of the return result. I propose the clarification to MPI_GET_PROCESSOR_NAME: Only the first resultlen characters of name are modified by MPI_GET_PROCESSOR_NAME. Bill >From: nissej@XXXXXXXXXXXXXXXXXXXX >X-Mailer: exmh version 2.1.1 (devel) >To: gropp@XXXXXXXXXXX >cc: pdc-staff@XXXXXXXXXX >Subject: Re: MPI_GET_PROCESSOR_NAME \0 or not? >Reply-To: pdc-staff@XXXXXXXXXX >Date: Wed, 01 Dec 1999 16:09:11 +0100 > > >Bill, > >I guess you don't remember me, but we met and talked somewhat during the >EuroPVM/MPI conference in Sabadell, Spain this year. I was the red >headed Swede that in the break asked you for an example where one would >like to use an IBSEND - and we both failed. > >Anyway - I am involved in a discussion with IBM on the >MPI_GET_PROCESSOR_NAME call in the Fortran MPI interface. The IBM >implementation returns a "\0" terminated string in the output argument >name although this zero-character is not counted in the output argument >resultlen. Thus, if you would do something like what is outlined below >you end up with an embedded "\0" character. > >character pid_string*3, name(MPI_MAX_PROCESSOR_NAME) > >call MPI_COMM_RANK(...my_proc_id...) >write(pid_string,*) my_proc_id >name="" >call MPI_GET_PROCESSOR_NAME(name,resultlen,ierror) >i=resultlen+8 >name(i:len(name))="is process id: "//pid_string > >The MPI standard does not say in its advice to users not to trust what >is beyond resultlen in the name argument of MPI_GET_PROCESSOR_NAME nor >does it say in its advice to implementors that it is not allowed to >touch the buffer beyond resultlen. > >In the C interface it makes perfectly sense to modify resultlen >characters and then add a trailing \0 and still don't count that, but >it should say in the standard that this happens. In the fortran >interface such behaviour this is of course not very elegant behaviour. >Do you dare to have an opinion on this or has it already been >discussed in the Forum perhaps? > >/Nils > >Encl: Message to IBM lab > Excerpts from relevant standards > Program example (run on IBM SP, poe 2.4 > Contact information > >---- My response to the IBM lab > >I think perhaps this is turning into a discussion about interpretation >of the MPI 1.0/2.0 standard. The standard says that the output argument >resultlen contains the length of the returned name. And that is >obviously correct. The standard also says: "The number of characters >written is returned in ... resultlen". > >The question really is "am I as a user allowed to think that the buffer >supplied to MPI_GET_PROCESSOR_NAME is unchanged in the positions >resultlen+1:len(name)" ? Or should I on return from the call always do >name(resultlen+1:len(name))="" do insert (yes this is Fortran) _SPACES_ >in the name string and then be able to print the content of the >variable name ? > >If the latter is true the maybe the MPI standard should add this in the >advice to users, otherwise the standard should emphasize in its advice >to implementors that the buffer should be untouched in the positions >beyond what is flagged in the output argument resultlen. > >I guess this also flags a need for clearing in the MPI standard for the >C interface whether the stringterminator "\0" should be counted in the >count for resultlen. > >/Nils > >-------------------------------- >Fortran 77 standard ANSI X3J3/90.4 >(http://www.fortran.com/fortran/F77_std/rjcnf.html) > >5.7 Character Substring > >A character substring is a contiguous portion of a character datum and is of >type character. > >-- > >4.8 Character Type > >A character datum is a string of characters. The string may consist of >any characters capable of representation in the processor. The blank >character is valid and significant in a character datum. The length of a >character datum is the number of characters in the string. A character >datum has one character storage unit in a storage sequence for each >character in the string. > >Each character in the string has a character position that is numbered >consecutively 1, 2, 3, etc. The number indicates the sequential position >of a character in the string, beginning at the left and proceeding to >the right. > > >-------------------------------- > >MPI: A Message-Passing Interface Standard > >p. 193, Chapter 7, MPI Environmental Management. > >MPI_GET_PROCESSOR_NAME() >[...] > >The numbers of characters actually written is returned in the output >argument, resultlen. > >[...] > >Advice to users: The user must provide at least ..... The user should >examine the output argument, resultlen, to determine the actual length >of the name. > >---------------------------------- >program get_name_bug >implicit none > >include 'mpif.h' > >integer:: ierr, namelen, charnum,i,lenofname > >integer(kind=1):: byte >character(len=MPI_MAX_PROCESSOR_NAME):: name='' > >call MPI_INIT(ierr) >call MPI_GET_PROCESSOR_NAME(name,namelen,ierr) > >lenofname=len(name) >print *,'namelen=',namelen >print *,'len(name)=',lenofname >print *,'len_trim(name)=',len_trim(name) >print *,'->',name,'<-' > >print '(30i4)',(i,i=1,lenofname) >print '(30a4)',(name(i:i),i=1,lenofname) >print '(30i4)',transfer(name(1:lenofname),mold=byte,size=lenofname) >do i=1,lenofname > if(transfer(name(i:i),mold=byte)==0)then > write(*,'(a4)',ADVANCE="NO") '^' > else > write(*,'(a4)',ADVANCE="NO") ' ' > endif >end do >write(*,'(/)') > >call MPI_FINALIZE(ierr) >end >-------------------------------------------------------------------------- >$ mpxlf90 mpi_get_name_bug.f -o mpi_get_name_bug > >Output abrreviated.... > >$ ./mpi_get_name_bug | cat -v > namelen= 17 > len(name)= 256 > len_trim(name)= 18 > ->r13n09.pdc.kth.se^@ [...] > >-- >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Nils Jönsson http://www.pdc.kth.se/ > Center for Parallel Computers e-mail: nissej@XXXXXXXXXX > Royal Institute of Technology Voice: +46-8-7909115 > KTH Fax: +46-8-247784 > S-100 44 Stockholm, Sweden Office: OB2, room 1546 >-----------------------------------------------------------------------