[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSIMap and OpenBSD (Was: Re: GSIMap and gcc 2.95)

From: Riccardo Mottola
Subject: Re: GSIMap and OpenBSD (Was: Re: GSIMap and gcc 2.95)
Date: Wed, 17 Aug 2011 00:19:17 +0200
User-agent: Mozilla/5.0 (X11; U; OpenBSD i386; en-US; rv: Gecko/20110216 SeaMonkey/2.0.11


I forgot to mention that it was OpenBSD/sparc

On my OpenBSD/x86 computer however I get the same problem and it has gcc 4.2

Thus it appears to be an OpenBSD problem? I reconfigured and made clean. I 
don't see any apparent OS difference there.
This may be an OpenBSD libc problem.  Can you check how NULL is defined?  I 
fixed a bug in FreeBSD libc a couple of years back that would cause this, and 
they may have inherited the same bug from some common ancestor.  In C, the 
definition of NULL is usually (void*)0, but in C++ it is supposed to be 0 
(except that 0 is an int so on LP64 this causes stack smashing on variadic 
functions, but I digress), and it's possible that they just #define it to 0 for 
C and C++.  GCC provides a builtin __null which works better - it's a special 
literal that is a 0 value in any pointer type.

This explains why a "compiler bug" as Fred put it persisted from gcc 2.95 to 4.2... and why it doesn't show up on other platforms with the same compiler versions.

If you replace the NULL with (void*)0 in GSIMap.h, does that fix it?

Fred suggested to write the macro as
#define GSI_MAP_CLEAR_VAL(node) GSI_MAP_WRITE_VAL(map, &node->value, (GSIMapVal)(void *)NULL)

If I try
#define GSI_MAP_CLEAR_VAL(node) GSI_MAP_WRITE_VAL(map, &node->value, (GSIMapVal)(void *)0)

It still compiles. What fix do you consider better ?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]