[PATCH] flood: (Updated) Add handler relative_times_sizes_process_stats
Summary:
[PATCH] flood: (Updated) Add handler relative_times_sizes_process_stats
This patch is an update of the original patch I sent February 7,
2003 to have report_relative include the bytes sent and received when
displaying statistics. I updated it against the current public source
from CVS and included the follow-up bugfix I sent later that day.
Please consider this patch experimental. I'm adding a new handler
so that the statistics from report_relative includes the request and
response sizes. An alternate solution might be to allow the configuration
to specify which columns to output. For example:
relative_times_process_stats
The default would be the current set of statistics. I'm not sure
I like that additional attribute, because not all process_stats
handlers would respect the attribute. Food for thought ...
Affected files:
flood_profile.c
flood_report_relative_times.c
flood_report_relative_times.h
This patch adds an alternative to the handler:
relative_times_process_stats
The new handler:
relative_times_sizes_process_stats
includes the number of bytes sent in the request and received in the
response. This patch retrieves the number of bytes sent and received
from data member "rbufsize" in the request (request_t) and response
(response_t) structures.
To report the true bytes sent and received, you should specify the
following handler in your profile:
generic_fullresp_recv_resp
The new handler allows you to calculate the bytes sent and received
along with the time spent sending and receiving the data. The new
columns precede the response status:
start, connect, write, read, close, sent, received, status, thread/process
ID, url
Here's a sample (the "112" and "1460" are new):
1044589747892106 40058 40058 40058 40058 112 1460 OK 108 http://localhost/
Index: flood_profile.c
===
RCS file: /home/cvspublic/httpd-test/flood/flood_profile.c,v
retrieving revision 1.24
diff -u -r1.24 flood_profile.c
--- flood_profile.c 12 Feb 2003 22:50:58 - 1.24
+++ flood_profile.c 13 Feb 2003 08:41:31 -
@@ -290,6 +290,7 @@
/* Relative Times Report */
{"report_init", "relative_times_report_init",
&relative_times_report_init},
{"process_stats","relative_times_process_stats",
&relative_times_process_stats},
+{"process_stats","relative_times_sizes_process_stats",
&relative_times_sizes_process_stats},
{"report_stats", "relative_times_report_stats",
&relative_times_report_stats},
{"destroy_report",
"relative_times_destroy_report",&relative_times_destroy_report},
Index: flood_report_relative_times.c
===
RCS file: /home/cvspublic/httpd-test/flood/flood_report_relative_times.c,v
retrieving revision 1.6
diff -u -r1.6 flood_report_relative_times.c
--- flood_report_relative_times.c 3 Feb 2003 17:10:56 - 1.6
+++ flood_report_relative_times.c 13 Feb 2003 08:41:31 -
@@ -76,31 +76,22 @@
return APR_SUCCESS;
}
-apr_status_t relative_times_process_stats(report_t *report, int verified,
request_t *req, response_t *resp, flood_timer_t *timer)
+static apr_status_t process_stats_tail(char *buf,
+ apr_size_t buflen,
+ const apr_size_t maxlen,
+ int verified,
+ const request_t *req)
{
-#define FLOOD_PRINT_BUF 256
-apr_size_t buflen;
-char buf[FLOOD_PRINT_BUF];
-
-buflen = apr_snprintf(buf, FLOOD_PRINT_BUF,
- "%" APR_INT64_T_FMT " %" APR_INT64_T_FMT
- " %" APR_INT64_T_FMT " %" APR_INT64_T_FMT " %"
APR_INT64_T_FMT,
- timer->begin,
- timer->connect - timer->begin,
- timer->write - timer->begin,
- timer->read - timer->begin,
- timer->close - timer->begin);
-
switch (verified)
{
case FLOOD_VALID:
-apr_snprintf(buf+buflen, FLOOD_PRINT_BUF-buflen, " OK ");
+apr_snprintf(buf + buflen, maxlen - buflen, " OK ");
break;
case FLOOD_INVALID:
-apr_snprintf(buf+buflen, FLOOD_PRINT_BUF-buflen, " FAIL ");
+apr_snprintf(buf + buflen, maxlen - buflen, " FAIL ");
break;
default:
-apr_snprintf(buf+buflen, FLOOD_PRINT_BUF-buflen, " %d ", verified);
+apr_snprintf(buf + buflen, maxlen - buflen, " %d ", verified);
}
/* FIXME: this call may need to be in a critical section */
@@ -111,6 +102,54 @@
#endif
return APR_SUCCESS;
+}
+
+/* The buffer size was changed from 256 to 384 to help accommodate
+ large URLs and several 64-bit integers. */
+#define FLOOD_PRINT_BUF 384
+
+apr_status_t relative_times_process_stats(report_t *report,
+
[PATCH] flood: Added generic_fullresp_recv_resp() to force full response.
Summary:
Added generic_fullresp_recv_resp() to force full response.
This patch adds a new handler that always retrieves the entire response.
This handler is needed because we currently do not have a way to tell
flood to always retrieve the entire response. We have a "wantresponse"
flag that tells the socket code whether or not to retrieve the entire
response. Handlers such as round_robin_create_req() set this flag based
on varying factors. With the new generic_fullresp_recv_resp() handler,
you can specify it in your section like this:
generic_fullresp_recv_resp
to cause flood to retrieve the entire response.
When used with the handler:
relative_times_process_stats
you can measure the total bytes sent and received with each request
and response.
Files affected by this patch:
flood_profile.c
flood_socket_generic.c
flood_socket_generic.h
Index: flood_profile.c
===
RCS file: /home/cvspublic/httpd-test/flood/flood_profile.c,v
retrieving revision 1.23
diff -u -r1.23 flood_profile.c
--- flood_profile.c 7 Feb 2003 07:39:21 - 1.23
+++ flood_profile.c 12 Feb 2003 16:10:03 -
@@ -252,6 +252,9 @@
/* Alternative Implementations that are currently available: */
+/* Always retrieve the full response */
+{"recv_resp","generic_fullresp_recv_resp",
&generic_fullresp_recv_resp},
+
/* Keep-Alive support */
{"socket_init", "keepalive_socket_init",&keepalive_socket_init},
{"begin_conn", "keepalive_begin_conn", &keepalive_begin_conn},
Index: flood_socket_generic.c
===
RCS file: /home/cvspublic/httpd-test/flood/flood_socket_generic.c,v
retrieving revision 1.8
diff -u -r1.8 flood_socket_generic.c
--- flood_socket_generic.c 3 Feb 2003 17:10:56 - 1.8
+++ flood_socket_generic.c 12 Feb 2003 16:10:03 -
@@ -201,6 +201,26 @@
}
/**
+ * This implementation always retrieves the full response.
+ * We temporarily set the "wantresponse" flag to true and
+ * call generic_recv_resp() to do the real work.
+ */
+apr_status_t generic_fullresp_recv_resp(response_t **resp,
+socket_t *sock,
+apr_pool_t *pool)
+{
+generic_socket_t *gsock = (generic_socket_t *)sock;
+int orig_wantresponse = gsock->wantresponse;
+apr_status_t status;
+
+gsock->wantresponse = 1;
+status = generic_recv_resp(resp, sock, pool);
+gsock->wantresponse = orig_wantresponse;
+
+return status;
+}
+
+/**
* Generic implementation for end_conn.
*/
apr_status_t generic_end_conn(socket_t *sock, request_t *req, response_t *resp)
Index: flood_socket_generic.h
===
RCS file: /home/cvspublic/httpd-test/flood/flood_socket_generic.h,v
retrieving revision 1.3
diff -u -r1.3 flood_socket_generic.h
--- flood_socket_generic.h 3 Feb 2003 17:10:56 - 1.3
+++ flood_socket_generic.h 12 Feb 2003 16:10:03 -
@@ -62,6 +62,7 @@
apr_status_t generic_socket_init(socket_t **sock, apr_pool_t *pool);
apr_status_t generic_begin_conn(socket_t *sock, request_t *req, apr_pool_t
*pool);
apr_status_t generic_send_req(socket_t *sock, request_t *req, apr_pool_t
*pool);
+apr_status_t generic_fullresp_recv_resp(response_t **resp, socket_t *sock,
apr_pool_t *pool);
apr_status_t generic_recv_resp(response_t **resp, socket_t *sock, apr_pool_t
*pool);
apr_status_t generic_end_conn(socket_t *sock, request_t *req, response_t
*resp);
apr_status_t generic_socket_destroy(socket_t *socket);
[PATCH] flood: Fixed compiler warning about signed/unsigned mismatch in generic_recv_resp()
Here's a minor patch for a compiler warning. I'll going to send a patch that
touches flood_socket_generic.c soon, so I figured it would be a good thing
to address the warning first.
Summary:
Fixed compiler warning about signed/unsigned mismatch in generic_recv_resp
()
This patch addresses the following compiler warning generated by the
Visual C++ 6 compiler:
flood_socket_generic.c(161) : warning C4018: '>' : signed/unsigned mismatch
We have two local variables declared as integers used in an expression
involving an unsigned type. I changed the variable declarations to
match the unsigned type to address the warning. All three variables
involved deal with memory sizes using apr_size_t, so it's safe to
change the declarations.
Index: flood_socket_generic.c
===
RCS file: /home/cvspublic/httpd-test/flood/flood_socket_generic.c,v
retrieving revision 1.8
diff -u -r1.8 flood_socket_generic.c
--- flood_socket_generic.c 3 Feb 2003 17:10:56 - 1.8
+++ flood_socket_generic.c 8 Feb 2003 02:40:31 -
@@ -134,7 +134,7 @@
apr_status_t generic_recv_resp(response_t **resp, socket_t *sock, apr_pool_t *
pool)
{
char b[MAX_DOC_LENGTH];
-int i;
+apr_size_t i;
response_t *new_resp;
apr_status_t status;
@@ -146,7 +146,7 @@
if (gsock->wantresponse)
{
/* Ugh, we want everything. */
-int currentalloc;
+apr_size_t currentalloc;
char *cp, *op;
new_resp->rbufsize = 0;
flood: Crash when no "usefarmer" specified.
Hi all, I looked a bit into this crash and see that it's because we end up accessing unitialized data. The code in question is in function run_farm() in flood_farm.c. When no usefarmer entries exist, we end up allocating a two-element array that looks like this: [0] uninitialized [1] NULL There's code in run_farm() that effectively does this: if we found no usefarmers, set count = 1 allocate an array of count + 1 elements to hold the names We'll end up referencing that 0'th element as though it's valid---which it is not. It seems like we should abort with an error if we find no usefarmer's specified. But the code keeps going. It's not clear what the intent is with allowing the code to proceed. I'll defer any further analysis to someone who's more familiar with this part of flood. Maybe this analysis thus far is of some help to someone. Here's the smallest test-case XML configuration file that triggers the crash: Bingo
Re: [PATCH] flood: Add handler relative_times_sizes_process_stats
Hi all,
The patch I sent contained a bug. The second change in flood_profile.c
causes the new relative_times_sizes_process_stats to always be used
if you specify relative_times for your report. I've included a patch to
fix the problem. I had mistakenly changed the list that's used to
initialize the handlers when you specify the relative_times report.
The fix is to remove the new relative_times_sizes_process_stats entry
from the array report_relative_times_group[].
I also discovered that the patch provided only enables recording the
buffer sizes for the request and response. But, there's some additional
work needed to ensure we're retrieving the entire response from the
server. I noticed that my report would state that flood received about
1K for a 18K image. The missing piece seems to be the "wantresponse"
flag in the request_t structure. For what I'm measuring (total bytes
sent and received), I need it to be true before flood calls either
generic_recv_resp() and keepalive_recv_resp() to have the response from
the server.
It seems we need to be able to conditionally turn on some kind of
"full-response" flag for the "relative_times_sizes_process_stats"
patch to be useful.
Cheers,
Phi-Long.
--- flood_profile.c.orig2003-02-07 09:34:02.0 -0800
+++ flood_profile.c 2003-02-07 14:01:16.0 -0800
@@ -306,7 +306,7 @@
const char * socket_generic_group[] = { "generic_socket_init",
"generic_begin_conn", "generic_send_req", "generic_recv_resp",
"generic_end_conn", "generic_socket_destroy", NULL };
const char * socket_keepalive_group[] = { "keepalive_socket_init",
"keepalive_begin_conn", "keepalive_send_req", "keepalive_recv_resp",
"keepalive_end_conn", "keepalive_socket_destroy", NULL };
const char * profile_round_robin_group[] = { "round_robin_profile_init",
"round_robin_get_next_url", "round_robin_create_req",
"round_robin_postprocess", "round_robin_loop_condition",
"round_robin_profile_destroy", NULL };
-const char * report_relative_times_group[] = { "relative_times_report_init",
"relative_times_process_stats", "relative_times_sizes_process_stats",
"relative_times_report_stats", "relative_times_destroy_report", NULL };
+const char * report_relative_times_group[] = { "relative_times_report_init",
"relative_times_process_stats", "relative_times_report_stats",
"relative_times_destroy_report", NULL };
profile_group_handler_t profile_group_handlers[] = {
{"report", "easy", report_easy_group },
--- Original Message Dated: Fri, 07 Feb 2003 08:22:58 -0800
|From: [EMAIL PROTECTED]
| To: [EMAIL PROTECTED]
| Subject: [PATCH] flood: Add handler relative_times_sizes_process_stats
| This patch adds an alternative to the handler:
| relative_times_process_stats
| The new handler:
| relative_times_sizes_process_stats
| includes the number of bytes sent in the request and received in the
| response. This patch retrieves the number of bytes sent and received
| from data member "rbufsize" in the request (request_t) and response
| (response_t) structures.
| ...
[PATCH] flood: Add handler relative_times_sizes_process_stats
This patch adds an alternative to the handler:
relative_times_process_stats
The new handler:
relative_times_sizes_process_stats
includes the number of bytes sent in the request and received in the
response. This patch retrieves the number of bytes sent and received
from data member "rbufsize" in the request (request_t) and response
(response_t) structures.
The new handler allows you to calculate the bytes sent and received
along with the time spent sending and receiving the data. The new
columns precede the response status:
start, connect, write, read, close, sent received status, thread/process ID,
url
Here's a sample (the "112" and "1460" are new):
1044589747892106 40058 40058 40058 40058 112 1460 OK 108 http://localhost/
My apologies for the odd handler name. I couldn't think of shorter,
yet descriptive, name.
Index: flood_profile.c
===
RCS file: /home/cvspublic/httpd-test/flood/flood_profile.c,v
retrieving revision 1.23
diff -u -r1.23 flood_profile.c
--- flood_profile.c 7 Feb 2003 07:39:21 - 1.23
+++ flood_profile.c 7 Feb 2003 16:02:21 -
@@ -287,6 +287,7 @@
/* Relative Times Report */
{"report_init", "relative_times_report_init",
&relative_times_report_init},
{"process_stats","relative_times_process_stats",
&relative_times_process_stats},
+{"process_stats","relative_times_sizes_process_stats",
&relative_times_sizes_process_stats},
{"report_stats", "relative_times_report_stats",
&relative_times_report_stats},
{"destroy_report",
"relative_times_destroy_report",&relative_times_destroy_report},
@@ -305,7 +306,7 @@
const char * socket_generic_group[] = { "generic_socket_init",
"generic_begin_conn", "generic_send_req", "generic_recv_resp",
"generic_end_conn", "generic_socket_destroy", NULL };
const char * socket_keepalive_group[] = { "keepalive_socket_init",
"keepalive_begin_conn", "keepalive_send_req", "keepalive_recv_resp",
"keepalive_end_conn", "keepalive_socket_destroy", NULL };
const char * profile_round_robin_group[] = { "round_robin_profile_init",
"round_robin_get_next_url", "round_robin_create_req",
"round_robin_postprocess", "round_robin_loop_condition",
"round_robin_profile_destroy", NULL };
-const char * report_relative_times_group[] = { "relative_times_report_init",
"relative_times_process_stats", "relative_times_report_stats",
"relative_times_destroy_report", NULL };
+const char * report_relative_times_group[] = { "relative_times_report_init",
"relative_times_process_stats", "relative_times_sizes_process_stats",
"relative_times_report_stats", "relative_times_destroy_report", NULL };
profile_group_handler_t profile_group_handlers[] = {
{"report", "easy", report_easy_group },
Index: flood_report_relative_times.c
===
RCS file: /home/cvspublic/httpd-test/flood/flood_report_relative_times.c,v
retrieving revision 1.6
diff -u -r1.6 flood_report_relative_times.c
--- flood_report_relative_times.c 3 Feb 2003 17:10:56 - 1.6
+++ flood_report_relative_times.c 7 Feb 2003 16:02:22 -
@@ -76,31 +76,22 @@
return APR_SUCCESS;
}
-apr_status_t relative_times_process_stats(report_t *report, int verified,
request_t *req, response_t *resp, flood_timer_t *timer)
+static apr_status_t process_stats_tail(char *buf,
+ apr_size_t buflen,
+ const apr_size_t maxlen,
+ int verified,
+ const request_t *req)
{
-#define FLOOD_PRINT_BUF 256
-apr_size_t buflen;
-char buf[FLOOD_PRINT_BUF];
-
-buflen = apr_snprintf(buf, FLOOD_PRINT_BUF,
- "%" APR_INT64_T_FMT " %" APR_INT64_T_FMT
- " %" APR_INT64_T_FMT " %" APR_INT64_T_FMT " %"
APR_INT64_T_FMT,
- timer->begin,
- timer->connect - timer->begin,
- timer->write - timer->begin,
- timer->read - timer->begin,
- timer->close - timer->begin);
-
switch (verified)
{
case FLOOD_VALID:
-apr_snprintf(buf+buflen, FLOOD_PRINT_BUF-buflen, " OK ");
+apr_snprintf(buf + buflen, maxlen - buflen, " OK ");
break;
case FLOOD_INVALID:
-apr_snprintf(buf+buflen, FLOOD_PRINT_BUF-buflen, " FAIL ");
+apr_snprintf(buf + buflen, maxlen - buflen, " FAIL ");
break;
default:
-apr_snprintf(buf+buflen, FLOOD_PRINT_BUF-buflen, " %d ", verified);
+apr_snprintf(buf + buflen, maxlen - buflen, " %d ", verified);
}
/* FIXME: this call may need to be in a critical section */
@@ -111,6 +102,54 @@
#endif
return APR_SUCCESS;
+}
+
+/* The buffer size was changed from 256 to 384 to help accommodate
+ large URLs a
[PATCH] flood: Add URL DELAYFACTOR to customize delays
Hi all,
I created the following patch so I could specify delays smaller than
one second.
This patch adds a new attribute called "delayfactor" to the
URL element. You use it to change the multiplication factor
applied to the values you specify for:
postdelay
postdelayprecision
predelay
predelayprecision
Flood previously treated all delays in seconds. With this patch,
you can change the delays to be handled in microseconds, milliseconds,
etc. The new attribute affects only the current URL element in
which it's used. If you do not specify delayfactor, then we retain
the existing behavior of treating delays in seconds.
The precision available to you when you specify DELAYFACTOR=1
is in microseconds, which is the documented precision of apr_sleep().
This patch includes an example in file examples/round-robin-example.xml.
Index: config.h.in
===
RCS file: /home/cvspublic/httpd-test/flood/config.h.in,v
retrieving revision 1.26
diff -u -r1.26 config.h.in
--- config.h.in 29 Jan 2003 06:07:49 - 1.26
+++ config.h.in 7 Feb 2003 01:07:42 -
@@ -25,6 +25,7 @@
#define XML_URLLIST_RESPONSE_TEMPLATE "responsetemplate"
#define XML_URLLIST_RESPONSE_NAME "responsename"
#define XML_URLLIST_PROXY "proxy"
+#define XML_URLLIST_DELAYFACTOR "delayfactor"
#define XML_URLLIST_PREDELAY "predelay"
#define XML_URLLIST_PREDELAYPRECISION "predelayprecision"
#define XML_URLLIST_POSTDELAY "postdelay"
Index: flood_round_robin.c
===
RCS file: /home/cvspublic/httpd-test/flood/flood_round_robin.c,v
retrieving revision 1.34
diff -u -r1.34 flood_round_robin.c
--- flood_round_robin.c 3 Feb 2003 17:10:56 - 1.34
+++ flood_round_robin.c 7 Feb 2003 01:07:42 -
@@ -404,10 +404,33 @@
/* Parse any attributes. */
if (e->attr)
{
+/* Default the delay factor so that all delays are measured
+ in seconds. When we're done examining all attributes, we
+ multiply all parsed delay values with the delay factor.
+ Variable delayfactor will be our initialized value below or
+ the value specified as an attribute. */
+apr_int64_t delayfactor = APR_USEC_PER_SEC;
+
apr_xml_attr *attr = e->attr;
while (attr)
{
-if (strncasecmp(attr->name, XML_URLLIST_METHOD,
+if (strncasecmp(attr->name, XML_URLLIST_DELAYFACTOR,
+FLOOD_STRLEN_MAX) == 0) {
+char *endptr;
+delayfactor = strtoll(attr->value, &endptr, 10);
+/* Allow a delayfactor of zero in case the user wants
+ to quickly disable all delay specifications for
+ the URL. */
+if ((*endptr != '\0') || (delayfactor < 0))
+{
+apr_file_printf(local_stderr,
+"Attribute %s has invalid value %s.\n",
+XML_URLLIST_DELAYFACTOR, attr->value);
+return APR_EGENERAL;
+}
+
+}
+else if (strncasecmp(attr->name, XML_URLLIST_METHOD,
FLOOD_STRLEN_MAX) == 0) {
if (strncasecmp(attr->value, XML_URLLIST_METHOD_POST, 4) == 0)
url->method = POST;
@@ -439,7 +462,6 @@
XML_URLLIST_PREDELAY, attr->value);
return APR_EGENERAL;
}
-url->predelay *= APR_USEC_PER_SEC;
}
else if (strncasecmp(attr->name, XML_URLLIST_PREDELAYPRECISION,
FLOOD_STRLEN_MAX) == 0) {
@@ -452,7 +474,6 @@
XML_URLLIST_PREDELAYPRECISION,
attr->value);
return APR_EGENERAL;
}
-url->predelayprecision *= APR_USEC_PER_SEC;
}
else if (strncasecmp(attr->name, XML_URLLIST_POSTDELAY,
FLOOD_STRLEN_MAX) == 0) {
@@ -465,7 +486,6 @@
XML_URLLIST_POSTDELAY, attr->value);
return APR_EGENERAL;
}
-url->postdelay *= APR_USEC_PER_SEC;
}
else if (strncasecmp(attr->name, XML_URLLIST_POSTDELAYPRECISION,
FLOOD_STRLEN_MAX) == 0) {
@@ -478,7 +498,6 @@
XML_URLLIST_POSTDELAYPRECISION,
attr->value);
return APR_EGENERAL;
}
-url->postdelayprecision *= APR_USEC_PER_SEC;
}
else if (strncasecmp(attr->name,
XML_URLLIST_PAYLOAD_TEMPLATE,
@@ -513,6 +532,20 @@
}
attr = attr->next;
}
+
+/* We do not really need
[PATCH] (flood) Handle invalid handler name in assign_profile_event_handler()
Summary:
Fixed assign_profile_event_handler() to handle nonexistent names.
This patch fixes a null dereference when you specify a profile event
handler that does not exist in the profile_event_handlers[] table.
Below is the smallest test case I was able to generate to trigger
the crash. Note that the entry for "profile_init" is "XXX".
profile
XXX
farmer
profile
Bingo
farmer
With this patch, flood generates the following message:
Invalid implementation (XXX) for this handler (profile_init)
Error running farmer 'farmer': This function has not been implemented on this
platform.
I did find another crash when attempting to generate the small
test case above. Take out ... in the
sample XML above. I did not investigate that crash.
Index: flood_profile.c
===
RCS file: /home/cvspublic/httpd-test/flood/flood_profile.c,v
retrieving revision 1.22
diff -u -r1.22 flood_profile.c
--- flood_profile.c 3 Feb 2003 17:10:56 - 1.22
+++ flood_profile.c 7 Feb 2003 03:14:54 -
@@ -329,7 +329,7 @@
{
profile_event_handler_t *p;
-for (p = &profile_event_handlers[0]; p; p++) {
+for (p = &profile_event_handlers[0]; p && (*p).handler_name; p++) {
/* these are case insensitive (both key and value) for the sake of
simplicity */
if (strncasecmp(impl_name, (*p).impl_name, FLOOD_STRLEN_MAX) == 0) {
if (strncasecmp(handler_name, (*p).handler_name, FLOOD_STRLEN_MAX)
== 0) {
Re: [PATCH] flood: Fixed floodenv.bat environment problem in Makefile.win.
Hi Bill, I think we're talking about two different styles of makefiles. When I refer to NMAKE makefiles, I'm talking about writing makefiles from scratch by a human being who knows to make the makefile maintainable and readable by another human being. The problems you mention with .mak files sound like the ones you get when you use the makefiles generated by the DevStudio IDE, by using the "Export Makefile" option in the Project menu. I think it should be possible to hand craft a makefile for NMAKE that will work in VS 5, 6, and 7 environments. (I'm haven't used VS 7, so I'm assuming it has NMAKE, CL, LINK, etc.?) Folks can submit patches to NMAKE makefiles without having to worry about format differences in the Visual Studio versions. I'll volunteer to write the makefile and send it out for review. The goal would be to keep all build settings and steps in that one makefile. The trivial next step would be to generate a DSP that invokes the makefile for debug and release configurations. In these days of IDEs and automake, I feel like a caveman when I advocate writing makefiles by hand. But, they always seemed more maintainable and manageable than those DSP files. I've had to diff way too many DSP files these past several years as they entered the Windows development environments. --- Original Message Dated: Tue, 04 Feb 2003 14:53:24 -0600 |From: "William A. Rowe, Jr." <[EMAIL PROTECTED]> | | But for CVS - the .mak files get too dirty. If we really had an automake | style system ... but ah ... this really isn't practical at the moment. Believe | me I've investigated almost every cross compilation between ms and the | several faux-unix win32 environments. It just isn't that simple. | | The point is that .dsp's (VS 6.0 format) are usable in VS 5.0, 6.0, convertable | in VS 7.0 and 7.1, and trivial to extract the real .mak files by a VS 6.0 user | like you or I. The .mak files don't fit well into CVS because of the massive | changes every time you alter minor things like dependencies. | ...
Re: [PATCH] flood: Fixed floodenv.bat environment problem in Makefile.win.
Thanks for the review and feedback, Bill. I agree with your assessment of the floodenv.bat changes to invoke other programs. In my dealings with DevStudio DSP files and NMAKE makefiles, I've always found myself juggling environment variables with similar contortions. Do we need to support the IDE environments with DSP/DSW files (and also the newer IDE formats)? As the IDE-based file formats have changed over the course of several VC++ releases, NMAKE has remain consistent. I've also found it easier to maintain the NMAKE makefiles than the DSP files (stable syntax, consolidate common settings in include makefiles, less noise than IDE-generated files, etc.). So, I advocate keeping the build system in NMAKE makefiles. If we do need to support IDE users, I would have the DSP invoke the NMAKE makefiles and specify debug/release. The goal is to keep the compiling and linking in the NMAKE makefiles. --- Original Message Dated: Tue, 04 Feb 2003 10:33:24 -0600 |From: "William A. Rowe, Jr." <[EMAIL PROTECTED]> | | I liked the earlier patch to enable/disable OpenSSL. But the patches | below indicate why we don't use batch files... we can't go digging | throughout the system and order the various VisualStudios and | PlatformSDKs correctly; that has to be up to the developer. | ... | The update to VisualStudio 6.0 format? +1 | Cleaning up the SSL envvars list and detection? +1 | Using floodenv as an 'invoker' of make? --1 | ...
[PATCH] flood: Fixed floodenv.bat environment problem in Makefile.win.
Summary:
Fixed floodenv.bat environment problem in Makefile.win.
This submission fixes the floodenv.bat environment problem. This problem
occurs when Makefile.win tries to set up variables for use by external
prorams using floodenv.bat. For example, Makefile.win invokes MSDEV
like this:
floodenv.bat
msdev flood.dsw /useenv /make ...
The invocation of floodenv.bat and MSDEV occur in independent
environments, so MSDEV does not inherit the environment variables set
by floodenv.bat. For the build to complete, you need to generate and
invoke floodenv.bat before building with NMAKE and Makefile.win.
For example:
nmake -f makefile.win floodenv.bat
floodenv.bat
nmake -f makefile.win
This patch fixes the problem by allowing Makefile.win to tell floodenv.bat
to set up the environment variables and optionally run some commands in
the new environment. When we need to invoke an external program like
DevStudio, we tell floodenv.bat to execute the program so that it gets
a properly initialized environment. The arguments to floodenv.bat
are optional, so you can still set up your environment using just
floodenv.bat.
NOTE: This patch is based on the patch for building without OpenSSL.
I sent this patch in an e-mail titled:
[PATCH] flood: Fixed Win32 build when not using OpenSSL
Below is a summary of the file changes.
* Added macro CFG_FLOOD to consolidate all the places
that evaluate:
flood - Win32 $(LONG)
They now just reference $(CFG_FLOOD).
* Added commentary to our floodenv.bat target.
* The floodenv.bat target no longer inserts an:
@echo off
at the top of the file. We now suppress the output
of each line with a leading "@" symbol. We do so
because we want the line invoking the optional
external command to echo the command so we can tell
what arguments and options are used.
* The floodenv.bat target now also writes to "$@", which
is "floodenv.bat". The usage helps minimize the places
that use "floodenv.bat", thereby making it easier to
maintain if we need to change the name in the future.
* Changed floodenv.bat so that when we specify optional
arguments to it, then it will execute the commands.
If you do not specify arguments, you get the old
behavior---floodenv.bat sets up your environment
and then exits.
* Created new macros to represent the different build
tools we use:
DEVENV_FLOOD: Uses DEVENV.
MAKE_FLOOD: Uses NMAKE to invoke flood.mak
(you need to generate flood.mak from within
DevStudio).
MSDEV_FLOOD: Uses MSDEV to invoke the VC6 flood.dsp
using the flood.dsw.
* Consolidated the build and clean targets with the new
macros:
DEVENV_FLOOD, MAKE_FLOOD, MSDEV_FLOOD
These macros consolidate the usage between the build and
clean targets. Several of the redundancy spread across
multiple lines are now in macros, and their uses are
simpler single lines.
* Added .a and .y files to the clean target. They are
"generated" files from the "install" target.
--- Makefile.win.orig Mon Feb 03 13:55:57 2003
+++ Makefile.winMon Feb 03 17:56:40 2003
@@ -101,16 +101,31 @@
LONG=Release
!ENDIF
+CFG_FLOOD = flood - Win32 $(LONG)
+
+# Floodenv.bat sets up environment variables and will optionally
+# execute any command in the new environment. If we're guaranteed we
+# ran on Windows NT and newer versions, then we can make use of:
+# goto :EOF
+# instead of:
+# goto :end
+# and
+# %*
+# instead of:
+# %1 ... %9
+# See "goto /?" and "call /?" for details.
floodenv.bat: Makefile.win
- echo @echo off>floodenv.bat
- echo set SRCLIB=$(SRCLIB)>>floodenv.bat
- echo set APRPATH=$(APRPATH)>>floodenv.bat
- echo set APRUTILPATH=$(APRUTILPATH)>>floodenv.bat
- echo set OPENSSLPATH=$(OPENSSLPATH)>>floodenv.bat
- echo set REGEXPATH=$(REGEXPATH)>>floodenv.bat
+ echo @set SRCLIB=$(SRCLIB)>$@
+ echo @set APRPATH=$(APRPATH)>>$@
+ echo @set APRUTILPATH=$(APRUTILPATH)>>$@
+ echo @set OPENSSLPATH=$(OPENSSLPATH)>>$@
+ echo @set REGEXPATH=$(REGEXPATH)>>$@
!IF "$(HAVE_SSL)" == "1"
- echo set LINKSSL=libeay32.lib ssleay32.lib
/libpath:"$(SSLBIN)">>floodenv.bat
+ echo @set LINKSSL=libeay32.lib ssleay32.lib /libpath:"$(SSLBIN)">>$@
!ENDIF
+ echo @if "%%1" == "" goto :end>>$@
+ echo call %%1 %%2 %%3 %%4 %%5 %%6 %%7 %%8 %%9 1>>$@
+ echo :end>>$@
regex.h: $(REGEXPATH)\pcreposix.h
copy "$(REGEXPATH)\pcreposix.h" regex.h < <<
@@ -146,41 +161,28 @@
!ENDIF
!ENDIF
-!IF EXIST("flood.mak")
-
-clean:
- -floodenv.bat
- $(MAKE) $(MAKEOPT) -f flood.mak CFG="flood - Win32 $(LONG)" RECURSE=0
CLEAN
- del config.h floodenv.bat regex.h
-
-build: config.h
- floodenv.bat
- $(MAKE) $(MAKEOPT) -f flood.mak CFG="flood - Win32 $(LONG)" RECURSE=0
+DEVENV_FLOOD = call floodenv.bat devenv flood.sln /useen
[PATCH] flood: Fixed Win32 build when not using OpenSSL
Summary:
Fixed the Win32 build to exclude the OpenSSL libraries when we
build without OpenSSL.
This patch changes the Windows flood build so that it links successfully
when you are building flood without OpenSSL. The changes move all
the link decisions regarding OpenSSL usage to Makefile.win. When you
now build flood without the OpenSSL libraries, MSDEV will display the
following message (which will not break the build):
flood.exe - 0 error(s), 11 warning(s)
The following environment variables were not found
$(LINKSSL)
NOTE: This patch upgrades the flood_test.dsp to DevStudio 6 format.
I previously sent a patch for this upgrade in an e-mail titled:
[PATCH] flood: Upgraded flood_test.dsp to MS DevStudio 6 format
Below are summaries of the per-file changes.
flood.dsp:
* Replaced OpenSSL libraries and lib path with LINKSSL.
flood_test.dsp:
* Replaced OpenSSL libraries and lib path with LINKSSL.
* Upgraded to DevStudio 6 format so I can verify that
flood_test.exe builds with and without the OpenSSL libraries.
Makefile.win:
* Changed macro SSLBIN to include the OPENSSLPATH directory.
The change consolidates the usage to just the SSLBIN definition.
References to $(OPENSSLPATH)\$(SSLBIN) become $(SSLBIN).
* Removed setting SSLBIN from floodenv.bat. The DSP files
no longer reference the SSLBIN variable directly. Previously,
when you built flood without the OpenSSL libraries, floodenv.bat
would try to unset SSLBIN. If you did not run floodenv.bat
before invoking the makefile, the build would fail. NMAKE would
invoke floodenv.bat, which tries to unset a variable that is
not defined---which results in an error in Windows (NT and 2000).
* We set the LINKSSL variable to include the libraries and add
the library's include path. When you build without OpenSSL,
the variable will be undefined and we will no longer include
the OpenSSL libraries.
I verified these changes by building the debug and release configurations
of flood and flood_test. I also built those configurations with the
debug and release builds of OpenSSL 0.9.7. For a sanity check, I ran
the resulting executables with no input to verify they load successfully.
They correctly complained about improper XML input.
Index: Makefile.win
===
RCS file: /home/cvspublic/httpd-test/flood/Makefile.win,v
retrieving revision 1.1
diff -u -r1.1 Makefile.win
--- Makefile.win31 May 2002 07:57:16 - 1.1
+++ Makefile.win3 Feb 2003 22:24:30 -
@@ -86,9 +86,9 @@
[del config.h]
!ENDIF
!IFDEF DEBUG
-SSLBIN=out32dll.dbg
+SSLBIN=$(OPENSSLPATH)\out32dll.dbg
!ELSE
-SSLBIN=out32dll
+SSLBIN=$(OPENSSLPATH)\out32dll
!ENDIF
HAVE_SSL=1
!ENDIF
@@ -108,7 +108,9 @@
echo set APRUTILPATH=$(APRUTILPATH)>>floodenv.bat
echo set OPENSSLPATH=$(OPENSSLPATH)>>floodenv.bat
echo set REGEXPATH=$(REGEXPATH)>>floodenv.bat
- echo set SSLBIN=$(SSLBIN)>>floodenv.bat
+!IF "$(HAVE_SSL)" == "1"
+ echo set LINKSSL=libeay32.lib ssleay32.lib
/libpath:"$(SSLBIN)">>floodenv.bat
+!ENDIF
regex.h: $(REGEXPATH)\pcreposix.h
copy "$(REGEXPATH)\pcreposix.h" regex.h < <<
@@ -193,8 +195,8 @@
copy LICENSE "$(INSTDIR)\LICENSE.txt" <.y
copy $(LONG)\flood.exe "$(INSTDIR)\bin" <.y
!IF EXIST("$(OPENSSLPATH)")
- copy $(OPENSSLPATH)\$(SSLBIN)\libeay32.dll "$(INSTDIR)\bin" <.y
- copy $(OPENSSLPATH)\$(SSLBIN)\ssleay32.dll "$(INSTDIR)\bin" <.y
+ copy $(SSLBIN)\libeay32.dll "$(INSTDIR)\bin" <.y
+ copy $(SSLBIN)\ssleay32.dll "$(INSTDIR)\bin" <.y
xcopy $(OPENSSLPATH)\certs "$(INSTDIR)\certs" < .a
type << >> "$(INSTDIR)\README.txt"
Index: flood.dsp
===
RCS file: /home/cvspublic/httpd-test/flood/flood.dsp,v
retrieving revision 1.4
diff -u -r1.4 flood.dsp
--- flood.dsp 5 Jun 2002 06:25:19 - 1.4
+++ flood.dsp 3 Feb 2003 22:24:30 -
@@ -50,7 +50,7 @@
# ADD BSC32 /nologo
LINK32=link.exe
# ADD BASE LINK32 kernel32.lib user32.lib wsock32.lib ws2_32.lib apr.lib
aprutil.lib /nologo /subsystem:console /map /machine:I386
-# ADD LINK32 kernel32.lib advapi32.lib wsock32.lib ws2_32.lib apr.lib
aprutil.lib pcreposix.lib libeay32.lib ssleay32.lib /nologo /subsystem:console
/map /machine:I386 /libpath:"$(APRPATH)\LibR" /libpath:"$(APRUTILPATH)\LibR"
/libpath:"$(OPENSSLPATH)\$(SSLBIN)" /libpath:"$(REGEXPATH)\LibR"
+# ADD LINK32 kernel32.lib advapi32.lib wsock32.lib ws2_32.lib apr.lib
aprutil.lib pcreposix.lib /nologo /subsystem:console /map /machine:I386
/libpath:"$(APRPATH)\LibR" /libpath:"$(APRUTILPATH)\LibR" $(LINKSSL)
/libpath:"$(REGEXPATH)\LibR"
!ELSEIF "$(CFG)" == "flood - Win32 Debug"
@@ -74,7 +74,7 @@
# ADD BSC32 /nologo
LINK32=link.exe
# ADD BASE LINK32 kernel32.lib advapi32.lib wsock32.lib ws2_32.lib apr.lib
aprutil.lib /nologo /subsystem:console /incremental:no /ma
(flood) Environment problems with floodenv.bat in Makefile.win
Hi all, I'm seeing a problem in the Windows build of flood with Makefile.win. The makefile generates a batch file that sets up various variables. In the command block of some targets, we call the batch file before invoking a tool like nmake, MSDEV, etc. For example: floodenv.bat msdev flood.dsw <... additional stuff ...> It looks like the intent is for floodenv.bat to set the environment variables and then have subsequent commands use those variables. I don't see this behavior occurring. If you run floodenv.bat before using the makefile.win, then all is okay. I suspect I haven't had problems until recently because I was running the floodenv.bat manually in my command prompt in order to build with the MSDEV IDE. To see the problem you need to make sure you don't call floodenv.bat before using Makefile.win. I've included a sample NMAKE makefile and some output to demonstrate the problem. The recursive NMAKE isn't picking up the setting of ENVVAR from the env.bat created. I have a fix in mind, which I'll send out when it's ready. Command: nmake -f env.mak test-env Sample output: Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. ENVVAR is empty or unset. echo set ENVVAR=SOMETHING> env.bat env.bat F> set ENVVAR=SOMETHING nmake -nologo -f env.mak ENVVAR is empty or unset. # --- Beginning of Makefile --- !if "$(ENVVAR)" == "" !message ENVVAR is empty or unset. !else !message Got ENVVAR: $(ENVVAR) !endif all: test-env: echo set ENVVAR=SOMETHING> env.bat env.bat nmake -nologo -f env.mak # --- End of Makefile ---
[PATCH] flood: Upgraded flood_test.dsp to MS DevStudio 6 format
Summary: * Updated flood_test.dsp to MS DevStudio 6 format This patch updates the file flood_test.dsp to Developer Studio (DevStudio) version 6. Developer Studio version 6 no longer needs to upgrade the DSP file on-the-fly when you load flood.dsw. This DSP file now has the same DevStudio version as flood.dsp and flood.dsw (which includes flood_test.dsp). This change is for the sake of convenience. If we need to modify flood_test.dsp in the future, we can do so as a separate step from upgrading the DSP. CVS will also no longer identify flood_test.dsp as "modified" after DevStudio upgrades it. Index: flood_test.dsp === RCS file: /home/cvspublic/httpd-test/flood/flood_test.dsp,v retrieving revision 1.1 diff -u -r1.1 flood_test.dsp --- flood_test.dsp 31 May 2002 08:27:07 - 1.1 +++ flood_test.dsp 29 Jan 2003 23:29:57 - @@ -1,5 +1,5 @@ # Microsoft Developer Studio Project File - Name="flood_test" - Package Owner=<4> -# Microsoft Developer Studio Generated Build File, Format Version 5.00 +# Microsoft Developer Studio Generated Build File, Format Version 6.00 # ** DO NOT EDIT ** # TARGTYPE "Win32 (x86) Console Application" 0x0103 @@ -22,6 +22,7 @@ !MESSAGE # Begin Project +# PROP AllowPerConfigDependencies 0 # PROP Scc_ProjName "" # PROP Scc_LocalPath "" CPP=cl.exe
[PATCH] flood: (Win32) Fixed link error apr_pstrmemdup in flood_socket_keepalive.c
Summary: * (Win32) Fixed link error apr_pstrmemdup in flood_socket_keepalive.c. This patch addresses a link error. The code invoked apr_pstrmemdup() in flood_socket_keepalive.c without including the proper declaration. The compiler generates its own guess, which is incorrect. The code now includes the file: apr_strings.h so that it picks up the proper declaration of apr_pstrmemdup. Below are examples of the compile-time warning and the link failures that this patch addresses. flood_socket_keepalive.c(407) : warning C4013: 'apr_pstrmemdup' undefined; assuming extern returning int flood_socket_keepalive.obj : error LNK2001: unresolved external symbol _apr_pstrmemdup Index: flood_socket_keepalive.c === RCS file: /home/cvspublic/httpd-test/flood/flood_socket_keepalive.c,v retrieving revision 1.15 diff -u -r1.15 flood_socket_keepalive.c --- flood_socket_keepalive.c22 Jul 2002 05:50:05 - 1.15 +++ flood_socket_keepalive.c28 Jan 2003 23:50:58 - @@ -53,6 +53,7 @@ */ #include +#include #if APR_HAVE_STDLIB_H #include /* rand/strtol */
[PATCH] flood: Fixed PASSTHROUGH collision in flood_round_robin.c
Summary:
* Fixed PASSTHROUGH collision in flood_round_robin.c.
This patch fixes compile errors in flood_round_robin.c
resulting from the Windows header file wingdi.h. That
header file defines PASSTHROUGH, which is the same
identifier used as an enumerated constant for type
expand_param_e. The enumerated constants now use a
prefix, "EPE_", to help make their names more unique.
Below are the compile errors this patch addresses:
flood_round_robin.c(102) : error C2059: syntax error : 'constant'
flood_round_robin.c(151) : error C2146: syntax error : missing ')' before
identifier 'set'
flood_round_robin.c(151) : error C2081: 'expand_param_e' : name in formal
parameter list illegal
flood_round_robin.c(151) : error C2061: syntax error : identifier 'set'
flood_round_robin.c(151) : error C2059: syntax error : ';'
flood_round_robin.c(151) : error C2059: syntax error : ')'
flood_round_robin.c(152) : error C2449: found '{' at file scope (missing
function header?)
flood_round_robin.c(235) : error C2059: syntax error : '}'
Index: flood_round_robin.c
===
RCS file: /home/cvspublic/httpd-test/flood/flood_round_robin.c,v
retrieving revision 1.32
diff -u -r1.32 flood_round_robin.c
--- flood_round_robin.c 16 Sep 2002 09:55:07 - 1.32
+++ flood_round_robin.c 28 Jan 2003 23:43:32 -
@@ -97,9 +97,9 @@
extern apr_file_t *local_stderr;
typedef enum {
-EXPAND,
-EXPAND_SET,
-PASSTHROUGH
+EPE_EXPAND,
+EPE_EXPAND_SET,
+EPE_PASSTHROUGH
} expand_param_e;
typedef struct {
@@ -236,12 +236,12 @@
static char *expand_param_string(round_robin_profile_t *rp, char *template)
{
-return handle_param_string(rp, template, EXPAND);
+return handle_param_string(rp, template, EPE_EXPAND);
}
static char *parse_param_string(round_robin_profile_t *rp, char *template)
{
-return handle_param_string(rp, template, EXPAND_SET);
+return handle_param_string(rp, template, EPE_EXPAND_SET);
}
/* Construct a request */
@@ -598,19 +598,19 @@
p->url[p->current_url].payloadtemplate =
handle_param_string(p,
p->url[p->current_url].payloadtemplate,
-PASSTHROUGH);
+EPE_PASSTHROUGH);
}
if (p->url[p->current_url].requesttemplate) {
p->url[p->current_url].requesttemplate =
handle_param_string(p,
p->url[p->current_url].requesttemplate,
-PASSTHROUGH);
+EPE_PASSTHROUGH);
}
if (p->url[p->current_url].responsetemplate) {
p->url[p->current_url].responsetemplate =
handle_param_string(p,
p->url[p->current_url].responsetemplate,
-PASSTHROUGH);
+EPE_PASSTHROUGH);
}
p->current_url++;
}
[PATCH] flood: Added error handling for failed config-file open
Summary:
* Added error handling for failed config-file open.
This patch adds error handling to the code that opens the
configuration file. When you specify an argument to the flood
program, it attempts to open it to read in configuration
information. Previously, there was no error handling, so
the code proceeded to use an invalid file handle when the
file open fails. The code now detects the failure and displays
an error message.
The standard error and output file-opens were moved earlier
in the program in case we need to display error messages
to standard error.
On Windows, using the invalid file handle results in an
access violation. The program now displays a message like
this:
Error opening configuration file: The system cannot find
the file specified. .
Index: flood.c
===
RCS file: /home/cvspublic/httpd-test/flood/flood.c,v
retrieving revision 1.8
diff -u -r1.8 flood.c
--- flood.c 31 May 2002 07:59:26 - 1.8
+++ flood.c 29 Jan 2003 00:09:37 -
@@ -144,16 +144,20 @@
ssl_init_socket(local_pool);
#endif /* FLOOD_HAS_OPENSSL */
+apr_file_open_stdout(&local_stdout, local_pool);
+apr_file_open_stderr(&local_stderr, local_pool);
+
if (argc == 1)
apr_file_open_stdin(&local_stdin, local_pool);
-else
+else if ((stat = apr_file_open(&local_stdin, argv[1], APR_READ,
+ APR_OS_DEFAULT, local_pool)) != APR_SUCCESS)
{
-apr_file_open(&local_stdin, argv[1], APR_READ, APR_OS_DEFAULT,
- local_pool);
+char buf[256];
+apr_strerror(stat, (char*) &buf, sizeof(buf));
+apr_file_printf(local_stderr, "Error opening configuration file:
%s.\n",
+(char*)&buf);
+exit(-1);
}
-
-apr_file_open_stdout(&local_stdout, local_pool);
-apr_file_open_stderr(&local_stderr, local_pool);
/* parse the config */
config = parse_config(local_stdin, local_pool);
[PATCH] flood: Fixed Win32 crash resulting from strtoll() macro.
Hi all,
This patch is the first in a series that will produce a running
executable on Win32 platforms with Microsoft Visual C++ 6.0.
My Win32 development environment is Microsoft Windows 2000
Service Pack 3 and MS Visual C++ 6.0 Service Pack 3. My FLOOD
source was checked out from CVS this morning.
Sincerely,
Phi-Long Tran
Summary:
* Fixed Win32 crash resulting from strtoll() macro.
This patch addresses a crash caused by the Win32 implementation
of the strtoll() macro in config.h, which is generated from
config.h.in. This patch fixes config.h.in. The change will
affect files using strtoll() on Win32 builds with an "old enough"
Microsoft Visual C/C++ compiler.
The addition operator ("+") has higher precedence than the conditional
operator ("a ? b : c"). The portion of the Win32 implementation of the
strtoll() macro in question is below:
*(e) = (char*)(p) + ((b) == 10) ? strspn((p), "0123456789") : 0
The compiler will evaluate the expression like this:
*(e) = ( (char*)(p) + ((b) == 10) ) ? strspn((p), "0123456789") : 0
The code was meant to evaluate like this:
*(e) = (char*)(p) + ( ((b) == 10) ? strspn((p), "0123456789") : 0 )
The code is effectively pointing "e" to the first nondigit character
starting at where "p" points to. Because of the precendence rules,
the invocation of strtoll() in set_seed() in file flood.c effectively
compiled to this code:
*(e) = strspn((p), "0123456789")
which yields an invalid address.
The above assignment triggers the compiler warning below.
flood.c(105) : warning C4047: '=' : 'char *' differs in levels of
indirection from 'const unsigned int '
The build produces seven occurrences of this warning. After the
code fix, those seven occurrences disappear.
When applying this fix, you should rebuild all files to ensure they
re-evaluate the corrected strtoll() macro from a newly generated
config.h file.
Index: config.h.in
===
RCS file: /home/cvspublic/httpd-test/flood/config.h.in,v
retrieving revision 1.25
diff -u -r1.25 config.h.in
--- config.h.in 16 Sep 2002 09:55:07 - 1.25
+++ config.h.in 29 Jan 2003 00:20:00 -
@@ -74,7 +74,7 @@
#ifdef WIN32
/* Gross Hack Alert */
#if _MSC_VER < 1300
-#define strtoll(p, e, b) ((*(e) = (char*)(p) + ((b) == 10) ? strspn((p),
"0123456789") : 0), _atoi64(p))
+#define strtoll(p, e, b) ((*(e) = (char*)(p) + (((b) == 10) ? strspn((p),
"0123456789") : 0)), _atoi64(p))
#else
#define strtoll(p, e, b) _strtoi64(p, e, b)
#endif
