Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Message-ID: <3909C4FB.3943D983@algroup.co.uk>
Date: Fri, 28 Apr 2000 18:06:03 +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
 test.c
References: <20000428143300.A23117@engelschall.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Ralf S. Engelschall" wrote:
> 
> In article <20000428064956.75303.qmail@locus.apache.org> you wrote:
> > dougm       00/04/27 23:49:55
> >
> >   Modified:    src/lib/apr/file_io/beos readwrite.c
> >                src/lib/apr/file_io/os2 dir.c open.c pipe.c readwrite.c
> >                src/lib/apr/file_io/unix readwrite.c
> >                src/lib/apr/file_io/win32 filedup.c fileio.h filestat.c
> >                         pipe.c readwrite.c
> >                src/lib/apr/include apr_general.h
> >                src/lib/apr/lib apr_pools.c apr_snprintf.c
> >                src/lib/apr/locks/os2 locks.c
> >                src/lib/apr/locks/win32 locks.c
> >                src/lib/apr/misc/win32 names.c start.c
> >                src/lib/apr/network_io/os2 sockets.c
> >                src/lib/apr/network_io/win32 sendrecv.c
> >                src/lib/apr/shmem/unix/mm mm.h mm_alloc.c mm_core.c
> >                         mm_global.c
> > [...]
> 
> Are you sure APR's MM should be converted, too? AFAIK MM inside APR
> doesn't include apr_general.h. MM is a stand-alone library which is just
> staying inside the APR tree. But it doesn't use APR, so it cannot (and
> IMHO also should not) use APR's APR_FALSE/APR_TRUE values.
> 
> BTW, I'm also personally not convinced that own APR_{TRUE,FALSE} values
> are very useful. FALSE is _ALWAYS_ 0 and TRUE is just not FALSE. So it
> is usually never a problem to use
> 
> #ifndef FALSE
> #define FALSE 0
> #endif
> #ifndef TRUE
> #define TRUE !FALSE
> #endif
> 
> even if a vendor header or a third-party header already defined FALSE
> (if it defined FALSE, it has to be defined to the value 0 and direct
> value comparisons with TRUE are de-facto illegal at all). So, I've never
> seen a problem with this in practice. NULL, FALSE and TRUE are more or
> less de-facto values for C programming and one can count on them. The
> reason why one defines it in own headers is just to make sure they are
> really always available (in case <stdlib.h> doesn't define NULL, etc).

+1.

APR_TRUE is a stupid idea.

Cheers,

Ben.

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