[petsc-dev] Problem with PETSC_NULL and variadic functions

Dmitry Karpeev karpeev at mcs.anl.gov
Thu Nov 10 08:11:56 CST 2011


On Wed, Nov 9, 2011 at 2:51 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
>  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++ :-)
>

libMesh and MOOSE use PETSc from C++.  If PETSc is compiled with a C
compiler, then there should be no problem, unless the  C++ code makes a
call to one of PETSc's variadic functions, right?

Dmitry.

>
>   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?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111110/d87f24e6/attachment.html>


More information about the petsc-dev mailing list