Bill, I thank you much for your input too. POSIX has no problem making you do the cast in C ??
int posix_memalign(void **memptr, size_t alignment, size_t size); I get why its that way now in MPI, I still don't like it ?? Tony cf, https://linux.die.net/man/3/posix_memalign posix_memalign(3): allocate aligned memory - Linux man page<https://linux.die.net/man/3/posix_memalign> The function posix_memalign() allocates size bytes and places the address of the allocated memory in *memptr. The address of the allocated memory will be a ... linux.die.net Anthony Skjellum, PhD Professor of Computer Science and Chair of Excellence Director, SimCenter University of Tennessee at Chattanooga (UTC) tony-skjel...@utc.edu [or skjel...@gmail.com] cell: 205-807-4968 ________________________________ From: William Gropp <wgr...@illinois.edu> Sent: Wednesday, October 14, 2020 3:48 PM To: Main MPI Forum mailing list <mpi-forum@lists.mpi-forum.org> Cc: Rolf Rabenseifner <rabenseif...@hlrs.de>; Skjellum, Anthony <tony-skjel...@utc.edu> Subject: Re: [Mpi-forum] Question about MPI_Alloc_mem 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<mailto: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 | 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 -- 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 _______________________________________________ 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
_______________________________________________ mpi-forum mailing list mpi-forum@lists.mpi-forum.org https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
