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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
