[petsc-dev] Problem with PETSC_NULL and variadic functions

[Dmitry Karpeev]

Is the problem that we might be using more registers than might be
necessary in a variadic function call?

On Wed, Nov 9, 2011 at 2:26 PM, Jed Brown <jedbrown at mcs.anl.gov> 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111109/874c1bd4/attachment.html>