Received: (qmail 64048 invoked by uid 501); 7 Mar 2001 12:29:40 -0000 Message-Id: <20010307122940.64047.qmail@apache.org> Date: 7 Mar 2001 12:29:40 -0000 From: Sam Liddicott Reply-To: sam@ananova.com To: submit@bugz.apache.org Subject: It would be nice (see patch) if mod_imap could handle negative numbers for it's paths X-Send-Pr-Version: 3.110 >Number: 7370 >Category: mod_imap >Synopsis: It would be nice (see patch) if mod_imap could handle negative numbers for it's paths >Confidential: no >Severity: non-critical >Priority: medium >Responsible: apache >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: apache >Arrival-Date: Wed Mar 07 04:30:01 PST 2001 >Closed-Date: >Last-Modified: >Originator: sam@ananova.com >Release: 1.3.17 >Organization: apache >Environment: Any >Description: It would be nice (see patch) if mod_imap could handle negative numbers for it's paths. My paths are generated from a postscript file and some co-ordinates are negative. As mod_imap stores points as floating point anyway, there's not much reason why negative integers should be forbidden. This patch * gets rid of -1 as a last-vertex signal and maintains a count for pointinpoly * allows parsing map files with negative integers * allows up to 500 vertex's * allows map file lines to be 8K long >How-To-Repeat: >Fix: --- src/modules/standard/mod_imap.c.small Wed Mar 7 10:34:47 2001 +++ src/modules/standard/mod_imap.c Wed Mar 7 10:28:32 2001 @@ -102,7 +102,7 @@ #include "util_script.h" #define IMAP_MAGIC_TYPE "application/x-httpd-imap" -#define MAXVERTS 100 +#define MAXVERTS 500 #define X 0 #define Y 1 @@ -204,23 +204,17 @@ #define fmin(a,b) (((a)>(b))?(b):(a)) #define fmax(a,b) (((a)>(b))?(a):(b)) -static int pointinpoly(const double point[2], double pgon[MAXVERTS][2]) +static int pointinpoly(int numverts, const double point[2], double pgon[MAXVERTS][2]) { - int i, numverts, crossings = 0; + int i, crossings = 0; double x = point[X], y = point[Y]; - for (numverts = 0; pgon[numverts][X] != -1 && numverts < MAXVERTS; - numverts++) { - /* just counting the vertexes */ - } - for (i = 0; i < numverts; i++) { double x1=pgon[i][X]; double y1=pgon[i][Y]; double x2=pgon[(i + 1) % numverts][X]; double y2=pgon[(i + 1) % numverts][Y]; double d=(y - y1) * (x2 - x1) - (x - x1) * (y2 - y1); - if ((y1 >= y) != (y2 >= y)) { crossings +=y2 - y1 >= 0 ? d >= 0 : d <= 0; } @@ -596,7 +590,7 @@ static int imap_handler(request_rec *r) { - char input[MAX_STRING_LEN]; + char input[HUGE_STRING_LEN]; char *directive; char *value; char *href_text; @@ -753,14 +747,14 @@ while (ap_isspace(*string_pos)) { /* past whitespace */ string_pos++; } - while (ap_isdigit(*string_pos)) { /* and the 1st number */ + while ((*string_pos=='-') || ap_isdigit(*string_pos)) { /* and the 1st number */ string_pos++; } string_pos++; /* skip the ',' */ while (ap_isspace(*string_pos)) { /* past any more whitespace */ string_pos++; } - while (ap_isdigit(*string_pos)) { /* 2nd number */ + while ((*string_pos=='-') || ap_isdigit(*string_pos)) { /* 2nd number */ string_pos++; } vertex++; @@ -769,8 +763,6 @@ We start where we left off of the last sscanf, not at the beginning. */ - pointarray[vertex][X] = -1; /* signals the end of vertices */ - if (showmenu) { if (!href_text) { read_quoted(&string_pos, &href_text); /* href text could @@ -786,15 +778,14 @@ } /* note that we don't make it past here if we are making a menu */ - if (testpoint[X] == -1 || pointarray[0][X] == -1) { + if (testpoint[X] == -1 || 0 == vertex) { continue; /* don't try the following tests if testpoints are invalid, or if there are no coordinates */ } if (!strcasecmp(directive, "poly")) { /* poly */ - - if (pointinpoly(testpoint, pointarray)) { + if (pointinpoly(vertex,testpoint, pointarray)) { ap_cfg_closefile(imap); redirect = imap_url(r, base, value); if (!redirect) { >Release-Note: >Audit-Trail: >Unformatted: [In order for any reply to be added to the PR database, you need] [to include in the Cc line and make sure the] [subject line starts with the report component and number, with ] [or without any 'Re:' prefixes (such as "general/1098:" or ] ["Re: general/1098:"). If the subject doesn't match this ] [pattern, your message will be misfiled and ignored. The ] ["apbugs" address is not added to the Cc line of messages from ] [the database automatically because of the potential for mail ] [loops. If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request from a ] [developer. Reply only with text; DO NOT SEND ATTACHMENTS! ]