[Mpi-forum] Question about MPI_Alloc_mem

[Skjellum, Anthony]

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-skjellum at utc.edu  [or skjellum at gmail.com]

cell: 205-807-4968


________________________________
From: mpi-forum <mpi-forum-bounces at lists.mpi-forum.org> on behalf of Rolf Rabenseifner via mpi-forum <mpi-forum at lists.mpi-forum.org>
Sent: Wednesday, October 14, 2020 1:32 PM
To: Main MPI Forum mailing list <mpi-forum at lists.mpi-forum.org>
Cc: Rolf Rabenseifner <rabenseifner at 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 at lists.mpi-forum.org>
> To: "Main MPI Forum mailing list" <mpi-forum at lists.mpi-forum.org>
> Cc: "Anthony Skjellum" <skjellum at 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:skjellum at gmail.com | skjellum at gmail.com ]
> Cell: +1-205-807-4968
>
>
>
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/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<http://www.hlrs.de/people/rabenseifner> .
Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) .
_______________________________________________
mpi-forum mailing list
mpi-forum at lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20201014/e8766444/attachment.html>