On Tuesday, December 17, 2002, at 12:29 PM, David Hill wrote:
Hi all,
Two problems, and a couple of minor issues encountered trying to build flood from CVS on tru64:
first: in flood_report_relative_times.c we have:
typedef void relative_times_report_t;
apr_status_t relative_times_report_init(report_t **report, config_t *config,
const char *profile_name, apr_pool_t *pool)
{
*report = apr_palloc(pool, sizeof(relative_times_report_t));
Our compiler (I would think correctly) chokes on the sizeof(void) in the apr_palloc().
What confuses me is what this what "report" is used for. Looks to me as if it is a placeholder and is not really used. If that is indeed the case then switching to something like void* would make my compiler happy. On the other hand.... switching it to use:
*report = apr_palloc(pool, sizeof(report_t *));
seems just as logical to me, as that matches the return type better.
It's probably just a typo, so doing sizeof(report_t*) is probably the right
way to go.
second: Tru64 does not have (nor need) a strtoll, our long is 64 bit anyway. Nor do we have strtoq (whatever that does). The following fixes it for me:
[EMAIL PROTECTED]:/home/ddhill/apache/flood/httpd-test/flood # ~/bin/diff -u config.h.orig config.h --- config.h.orig 2002-12-17 13:36:33.000000000 -0500 +++ config.h 2002-12-17 13:51:25.000000000 -0500 @@ -80,6 +80,8 @@ #endif #elif !FLOOD_HAS_STRTOLL && FLOOD_HAS_STRTOQ #define strtoll(p, e, b) strtoq(p, e, b) +#else +#define strtoll(p, e, b) strtol(p, e, b) #endif #endif /* __config_h */
It could be argued I suppose that this should be special cased for Tru64 using
#if defined(__alpha) && defined(__osf__)
but I would think that in the absence of strtoll or strtoq, this is the best fallback.
That might be an ok workaround, but we should eventually hide this inside APR, since this will probably bite us later.
A minor (probably issue): in flood_net.h and flood_net_ssl.h, for the function read_socket(),
buflen should really be a apr_size_t. On Tru64, this is a long and not an int and causes a warning or two. It is proably not a dangerous error though.
Could you submit a patch for that?
-aaron
