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).
