To summarize:
In C we could do #define PETSC_NULL ((void*) 0) and every thing
would be fine
In C++ this won't work and there is no alternative except a standard that
is 2 months old (but for those programming in C++ this is not really a problem
because there is really no need for varargs in proper C++ code).
Questions:
1) Why won't it work in C++? Note that PETSC_NULL truly is suppose to
always be used as a null pointer and should never be used as 0; if int 0 is
intended then int 0 should be used.
2) Can we at least fix it for C by using #define PETSC_NULL
((void*) 0) in C and using 0 in C++. After all nobody really uses PETSc from
C++ :-)
Barry
On Nov 9, 2011, at 2:26 PM, Jed Brown wrote:
> #define PETSC_NULL 0
>
> This is an "int" value, though it's special in that it will be implicitly
> converted to a null pointer (not even necessary bitwise 0, according to the
> standard) if its value is assigned to a pointer. If we pass it to a function
> with unspecified arguments (e.g. variadic), then it will be passed as an int.
>
> We usually use PETSC_NULL in place of a pointer value. It is common for an
> entire pointer-length integer register to be used when passing an "int". Most
> architectures pass the first few arguments in registers before passing on the
> stack. We seem to be getting lucky so far in that we haven't used functions
> like DMCompositeGetAccess() on systems where sizeof(void*) != sizeof(int),
> with more arguments than are passed in registers.
>
> C99 has stddef.h define NULL to be a null pointer constant ((void*)0). This
> is not compatible with C++ and I don't see a simple resolution.
>
> It doesn't work in C++ because there is no implicit pointer conversion from
> void*. So instead of having a pointer-valued NULL like in C, they define NULL
> to be 0 or 0L, which is just an integer (unless assigned to a pointer in
> which case 0 is special and is converted implicitly).
>
> Since it was 2011 and there was still no way to define a null pointer in C++,
> the new standard C++11 introduces a new keyword nullptr. Considering that we
> are still not allowed to use C99 in PETSc, it seems unlikely that we would be
> allowed to rely on C++11 which is less than two months old.
>
>
> We could pass a "format string" indicating which entries we were actually
> requesting. Other ideas?