On 17/02/11 00:03, Kinkie wrote:
On Wed, Feb 16, 2011 at 11:37 AM, Amos Jeffries<[email protected]> wrote:
On 16/02/11 22:55, Kinkie wrote:
On Wed, Feb 16, 2011 at 10:46 AM, Amos Jeffries<[email protected]>
wrote:
On 16/02/11 04:17, Kinkie wrote:
Hi all,
RefCount is a pure c++ artifact, and at least on my Ubuntu system it
breaks the build. On the hudson nodes this doesn't seem to happen,
probably due to indirect include from<iostream>.
From stdio.h is that route most likely then. Or any number of other
system
includes which define it.
How to deal with it? Should we use the c++ "0" construct or try to
define the NULL symbol somehow?
Alex brought removal up a while ago. My arguments about portability have
since been proven obsolete (yay).
So we are left with the opinions (me, Robert, Henrik IIRC) that use of
NULL
makes it absolutely clear that the thing being tested is a pointer and
not
an integer, no C++ magic conversion mistakes.
If need be we can add this to compat/compat_shared.h:
#if !defined(NULL)
#define NULL ((void*)0)
#endif
Stroustrup's take on the issue
(http://www2.research.att.com/~bs/bs_faq2.html#null).
It seems reasonable to me.
Well if you want to erase NULL we can probably cope.
It's an aesthetic thing more than a problem fix now.
For RefCount the problem is probably that it doesn't include anything
(except for<iostream> which may or may not define NULL indirectly).
Simply including "config.h" seems to do the trick; if it builds I'll commit it.
config.h includes stdio.h indirectly which defines it. So it remains a
maybe in the long term.
So... what object are you building that does not include config.h as the
first include of it's .cc? That is a buggy .cc file.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.11
Beta testers wanted for 3.2.0.5
