Mailing-List: contact test-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: test-dev@httpd.apache.org
Date: Fri, 17 Aug 2001 09:34:28 -0700
From: Aaron Bannert <aaron@clove.org>
To: test-dev@httpd.apache.org
Subject: Re: cvs commit: httpd-test/flood config.h.in configure.in flood.c
 flood_round_robin.c
Message-ID: <20010817093428.G16178@clove.org>
References: <20010817074402.41478.qmail@icarus.apache.org>
 <20010817083020.A16178@clove.org> <20010817090053.E16178@clove.org>
 <20010817091926.B1397@ebuilt.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010817091926.B1397@ebuilt.com>;
 from jerenkrantz@ebuilt.com on Fri, Aug 17, 2001 at 09:19:26AM -0700

On Fri, Aug 17, 2001 at 09:19:26AM -0700, Justin Erenkrantz wrote:
> On Fri, Aug 17, 2001 at 09:00:53AM -0700, Aaron Bannert wrote:
> > Let me be more clear here. I'd prefer if we did the check for
> > 'rand' 'rand48' 'random' (and possibly also /dev/urandom) and
> > set each of FLOOD_HAS_RAND* individually. This is the way you are
> > using it in the code, where you have something like:
> > 
> > #if FLOOD_HAS_RAND
> >    rand()
> > #elsif FLOOD_HAS_RAND48
> >    rand48()
> > ...
> 
> Eh?  No.  We shouldn't do it that way.  I want the configure to pick the
> "best" PRNG available and I want to use it.  In the code snippet you
> just posted, you'd almost always use rand - which is the absolutely
> worst one you could use.  So, you'd have to code it like:
> 
> #if FLOOD_HAS_RANDOM
>     random()
> #elsif FLOOD_HAS_RAND48
>     rand48()
> #else FLOOD_HAS_RAND
>     rand()
> #endif
> 
> -1.  The actual code is almost always going to want USE #defines
> not HAS #defines.  Relying on the order of HAS is counter-intuitive -
> therefore, I'll veto the hell out of it.  =-)  You would typically
> want the HAS #defines when they are all equivalent functions - you
> want the USE #defines when there is a definite priority as to which
> one you want (and it is very possible that a system will have all
> of the different possibilities).  Think of shmem in APR...

Of course you don't want to use rand() if others are available!

There is no order inherent in HAS semantics. HAS merely defines the
existance of some function or functionality, it does not define any
relationship between other similiar functions or functionality.

What you are doing in code should be done with USE semantics.

> > That allows us to choose which rand we have in the #ifdefs instead of
> > relying on autoconf. If this is unsatisfactory, we'll have to go with
> > the compromise, which is FLOOD_USE_RAND* and FLOOD_HAS_RAND*
> 
> It should be trivial to add FLOOD_HAS_RAND* macros from what I committed
> last night - I just don't think you would add any value by having the
> HAS_RAND* macros for the reasons described above.

This is all really NBD, I'm just pointing out that by what you were doing
in code should have been done with USE instead of HAS, and that it would
be no big deal to add HAS and USE.

-aaron