[petsc-dev] Arguments that are logically void**

Barry Smith bsmith at mcs.anl.gov
Mon Jun 6 13:00:34 CDT 2011


  So is the only benefit that one does not need the extra characters (void**) in front of the argument?

   Doesn't seem like much of a benefit? At this point I think doing it either way is fine but if we are inconsistent we should fix some of them to be consistent. I am leaning to vote for the (void**) approach; it is clearer when one looks at code.


    Barry




On Jun 6, 2011, at 6:40 AM, Jed Brown wrote:

> There are a few places in PETSc where arguments that are logically void** are implemented as void*. This removes the need for the user to provide an explicit cast, and is backward compatible. MPI adopted this convention between version 1.0 and 1.1. For example,
> 
> int MPI_Attr_get(MPI_Comm comm, int keyval,void **attribute_val, int *flag )           /* MPI-1.0 */
> 
> int MPI_Attr_get(MPI_Comm comm, int keyval,void *attribute_val, int *flag )            /* MPI-1.1 and later */
> 
> 
> Inside the implementation, the actual assignment would look something like
> 
> *(void**)attribute_val = comm->attr_table[keyval];
> 
> 
> Should we adopt this uniformly? The benefit is that the user doesn't need to *always* cast to (void**) every time they call the function.
> 
> The downside is that the function signature does not make it obvious that the user should pass the address of their pointer. On the other hand, C pass-by-value semantics guarantee that the function couldn't do anything like what it says if you didn't pass in the address of your pointer.
> 
> 
> Note that this change cannot be made for (void(**)(void)) function arguments because function pointers are not castable to non-function pointers (as per the C standard, though it works on many platforms).




More information about the petsc-dev mailing list