httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: cvs commit: httpd-test/flood config.h.in configure.in flood.c flood_round_robin.c
Date Fri, 17 Aug 2001 16:19:26 GMT
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...

> 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.

And, really, this should be moved into APR not flood.

My $.02.  -- justin


Mime
View raw message