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>
