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

[Riccardo Mottola]

Hi,
> > Hi,
> >
> > 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 ?

Riccardo