Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Message-ID: <390AB791.8B31175E@algroup.co.uk>
Date: Sat, 29 Apr 2000 11:21:05 +0100
From: Ben Laurie <ben@algroup.co.uk>
Organization: A.L. Group plc
MIME-Version: 1.0
To: new-httpd@apache.org
Subject: Re: cvs commit: apache-2.0/src/os/win32/installer/installdll/test
References: <200004282037.QAA22916@devsys.jaguNET.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jim Jagielski wrote:
> 
> Ben Laurie wrote:
> >
> > For God's sake. Get real.
> 
> Nah. Too fun not to :)
> 
> >
> > #define int double
> >
> > we get weirdness. Are we going to invent ap_int and ap_double to "fix"
> > this problem?
> >
> 
> I don't think TRUE or FALSE falls into the same sort of "protected
> cookie" that int et.al. does :) Also, it's not so much FALSE which
> is the one to be "careful" about, it's TRUE.

Hmm. Well, K&R define the value of "true" to be 1, so, although they
don't protect the name, they certainly do protect the value.

> What we're saying is that we want FALSE to be 0, but to avoid compiler
> (OK, preprocessor) warnings we only force it if not already set. My
> point is why not just force it and say to hell with the world :) :)

Because you get warnings. I'd be OK with:

#ifdef TRUE
# undef TRUE
#endif
#define TRUE 1

> If doing that scares people, then we "protect" the real ones
> with good ol' APR_ ;)

That's just too stupid.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html