My previous email (probably crossing paths with Tony’s reply) addressed most of
this. The one thing that I want to add is that the API choice made in MPI for
the C binding, both in the MPI-1 attribute get functions and here, has nothing
to do with the Fortran binding. These were made to match C’s limitations on
anonymous pointers, and to avoid requiring pointer casts.
Bill
William Gropp
Director and Chief Scientist, NCSA
Thomas M. Siebel Chair in Computer Science
University of Illinois Urbana-Champaign
> On Oct 14, 2020, at 2:42 PM, Skjellum, Anthony via mpi-forum
> <mpi-forum@lists.mpi-forum.org> wrote:
>
> Rolf, the rationale is not clear at all to me: "to facilitate type casting"
> is self-understood or a canonical term of art. I've been programming in C for
> 40 years... and I never would write the API as we have done it there.
>
> For pointers, out arguments are literally truthful: void **ptr is an out
> argument of a void pointer, and void *ptr is an in argument of a void pointer.
>
> {Years ago, before there was void *, we would have written char **ptr for a
> char out argument (and cast it to whatever type we wanted), and char *ptr for
> an in point argument. }
>
> The fact that a void ** can stand in the place of a void * is clearly a
> weakened typing in the language, because void * can point at anything
> (unknown). Since a void * is a pointer, it can also hold a pointer to a
> pointer to void, sure. But the intent of the second * is to remind you that
> you have an out argument. And you *must* pass a pointer to a pointer for the
> API to work in C.
>
> Somehow this is helping the Fortran and C_PTR API of Fortran, as it states.
> So the C API is made this way for convenience of Fortran.
>
> The rationale shows the argument with the & to pass the pointer to the API by
> reference. But, the rationale is not necessarily normative. A reasonable
> person reads the standard, sees void * and passes the baseptr without the &.
>
>
> Seems like a bad API to me.
>
> Tony
>
>
> Anthony Skjellum, PhD
> Professor of Computer Science and Chair of Excellence
> Director, SimCenter
> University of Tennessee at Chattanooga (UTC)
> tony-skjel...@utc.edu <mailto:tony-skjel...@utc.edu> [or skjel...@gmail.com
> <mailto:skjel...@gmail.com>]
> cell: 205-807-4968
>
> From: mpi-forum <mpi-forum-boun...@lists.mpi-forum.org
> <mailto:mpi-forum-boun...@lists.mpi-forum.org>> on behalf of Rolf
> Rabenseifner via mpi-forum <mpi-forum@lists.mpi-forum.org
> <mailto:mpi-forum@lists.mpi-forum.org>>
> Sent: Wednesday, October 14, 2020 1:32 PM
> To: Main MPI Forum mailing list <mpi-forum@lists.mpi-forum.org
> <mailto:mpi-forum@lists.mpi-forum.org>>
> Cc: Rolf Rabenseifner <rabenseif...@hlrs.de <mailto:rabenseif...@hlrs.de>>
> Subject: Re: [Mpi-forum] Question about MPI_Alloc_mem
>
> Dear Tony,
>
> please read MPI-3.1 page 338, lines 36-41.
> Do these lines resolve your question?
>
> Best regards
> Rolf
>
> ----- Original Message -----
> > From: "Main MPI Forum mailing list" <mpi-forum@lists.mpi-forum.org
> > <mailto:mpi-forum@lists.mpi-forum.org>>
> > To: "Main MPI Forum mailing list" <mpi-forum@lists.mpi-forum.org
> > <mailto:mpi-forum@lists.mpi-forum.org>>
> > Cc: "Anthony Skjellum" <skjel...@gmail.com <mailto:skjel...@gmail.com>>
> > Sent: Wednesday, October 14, 2020 7:01:54 PM
> > Subject: [Mpi-forum] Question about MPI_Alloc_mem
>
> > Folks, I know we have had this function for a long time, and I've
> > implemented
> > ports of MPI that actually use it (e.g., with pre-pinned memory). But, I am
> > trying to understand the logic for why baseptr is passed by value, instead
> > of
> > by reference. In C, everything is by value, so the last argument in normal C
> > programs would be void **baseptr.
> >
> > The standard has:
> > int MPI_Alloc_mem(MPI_Aint size, MPI_Info info, void *baseptr);
> > Now, MPICC/GCC takes this with
> > void *memory = (void *)0;
> > int error = MPI_Alloc_mem(1024, MPI_INFO_NULL, &memory);
> > and you get the memory allocated properly.
> > What is more, this is incorrect:
> > int error = MPI_Alloc_mem(1024, MPI_INFO_NULL, memory);
> > although it compiles fine because that is, indeed, the API.
> > Why would we have the pointer going in by value, when it is coming out
> > as an OUT argument?
> > Isn't this plain wrong? void **baseptr means ---> I am passing you the
> > address of a void pointer.
> > Every viable implementation must do *(void **)baseptr = ...
> > when providing the "malloc'd/special" memory. So... why did we fudge
> > the C API. Is there some tie-in with the Fortran API?
> > Thanks in advance,
> > Tony Skjellum
> >
> >
> > --
> > Anthony Skjellum, PhD
> > [ mailto:skjel...@gmail.com <mailto:skjel...@gmail.com> |
> > skjel...@gmail.com <mailto:skjel...@gmail.com> ]
> > Cell: +1-205-807-4968
> >
> >
> >
> > _______________________________________________
> > mpi-forum mailing list
> > mpi-forum@lists.mpi-forum.org <mailto:mpi-forum@lists.mpi-forum.org>
> > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
> > <https://lists.mpi-forum.org/mailman/listinfo/mpi-forum>
>
> --
> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseif...@hlrs.de
> <mailto:rabenseif...@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
> <http://www.hlrs.de/people/rabenseifner> .
> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) .
> _______________________________________________
> mpi-forum mailing list
> mpi-forum@lists.mpi-forum.org <mailto:mpi-forum@lists.mpi-forum.org>
> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
> <https://lists.mpi-forum.org/mailman/listinfo/mpi-forum>
> _______________________________________________
> mpi-forum mailing list
> mpi-forum@lists.mpi-forum.org <mailto:mpi-forum@lists.mpi-forum.org>
> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
> <https://lists.mpi-forum.org/mailman/listinfo/mpi-forum>
_______________________________________________
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
