[PATCH] Fixes sentinel warnings on GCC4

[Chris Shoemaker]

On Mon, Dec 05, 2005 at 08:39:15PM -0500, David Hampton wrote:
> On Mon, 2005-12-05 at 18:28 -0500, Chris Shoemaker wrote:
> > On Mon, Dec 05, 2005 at 05:26:34PM -0500, Derek Atkins wrote:
> > > 
> > > ... we're still trying to analyze the issue and figure out what's really
> > > going on.  I.e., there's no plan to make any changes until we understand
> > > the problem.  David just went and tried to reproduce this on an amd64
> > > machine and could not reproduce it.  Then we hear back that these errors
> > > are on a 32-bit machine..  (all this is on IRC, and all in the last
> > > few minutes)..   So..  We're still trying to figure out what the REAL
> > > problem is before we consider this a gnucash  bug.
> 
> I checked the 32 bit Intel and 64 bit AMD systems that I have access to.
> On all of these machines NULL is defined as "((void *)0)", and they all
> compile gnucash cleanly.  The only way I can force these errors to occur
> is to throw away the existing definition of NULL (as defined
> in /usr/lib/gcc/<xxx>/4.0.2/include/stddef.h) and explicitly redefine
> NULL to be an untyped "0".  Even then, I only see the problem occur when
> compiling on an AMD64 system.  For that matter, to even elicit the error
> I have to redefine NULL after all the system header files have been
> included, or it is forced it back to the "((void*)0)" definition.

If NULL is ((void*)0) you won't have any problem using NULL as a
sentinel, but using that definition of NULL opens up the possibility
of writing code that works with one implementation and not with
another.  Specifically, you couldn't say "int *i = ((int *) NULL)" and
be sure it would mean the same thing for every compiler.

> I have no explanation why Sjoerd is seeing this problem on a 32bit
> system.  The only theory I can come up with is that his compiler is
> treating C files as C++ files, and is thereby using a definition of NULL
> as an untyped zero.  He would then also have to be compiling with the
> -Wstrict-null-sentinel argument, which is only allowed for C++ compiles
> and is specifically not included in the -Wall argument.
> 
> > You misunderstand me.  This *is* a problem, and we *should* fix it.
> 
> No, its not a problem and we do not need to fix anything. 
> 
> > The C-language rule is "always cast NULL when used as a sentinel to a
> > variadic function, otherwise you're accidentally passing integer
> > zero, which is wrong."
> 
> And as far as I can tell that's exactly what the GCC compiler provides
> when compiling C code.  On 32 bit systems and 64 bit systems.

Do we want to ship code that only works with a system that decides to
helpfully #define NULL ((void*)0), when another system may very
correctly #define NULL 0?  

The #define NULL 0 case is explicitly allowed by the ISO C standard,
and it's easy to write portable code that works for that case, so why
wouldn't we?

-chris