Re: QNX 6.1a mod/peer review

2002-05-24 Thread Justin Erenkrantz
[ Moving to [EMAIL PROTECTED] which is the right list for this. ] Comments inline. On Thu, May 23, 2002 at 10:28:08AM -0700, Davide Berti wrote: --- httpd-2.0.36/srclib/apr/locks/unix/proc_mutex.c Mon Apr 8 23:56:56 2002 +++ ../httpd-2.0.36/srclib/apr/locks/unix/proc_mutex.c Wed May 8

match_boyer_moore_horspool() looping on icarus

2002-05-24 Thread Cliff Woolley
Root: FYI, Greg Ames gave me the heads up and I've killed this one child off... it seems to be a relatively odd input that caused the loop, so I won't back icarus down to the ancient 2.0.18 nor to 2.0.36 for now... I'll just leave it on 2.0.37-dev and keep a closer eye on it. For everyone else,

RE: Local sockets

2002-05-24 Thread Karsten Paige Huneycutt
On Wed, 22 May 2002, William A. Rowe, Jr. wrote: Realize that this is a HUGE shortcoming for Win32, and functionality that we need addressed for Windows. With no fork() implementation whatsoever, we need to be able to pass fd's (apr_socket_t's, apr_file_t's and many other low level objects)

Re: match_boyer_moore_horspool() looping on icarus

2002-05-24 Thread Cliff Woolley
On Thu, 23 May 2002, Cliff Woolley wrote: #0 match_boyer_moore_horspool (this_pattern=0x8111cf0, s=0x8161dc4 Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; ), slen=58) at apr_strmatch.c:133 (Note that -71 is a non-printable superscript 1 or something.) PS: It's not evident from

Re: match_boyer_moore_horspool() looping on icarus

2002-05-24 Thread Brian Pane
Cliff Woolley wrote: And yes, s_next *is* less than s_end. So the question is: why doesn't s_next get incremented? (gdb) p *s_next $3 = -71 '' (gdb) p shift[*s_next] $4 = 0 Ah. Oops. (Note that -71 is a non-printable superscript 1 or something.) Perhaps s_next needs to be unsigned? Thanks for

Re: apr_date_parse_rfc segv

2002-05-24 Thread Jeff Trawick
Cliff Woolley [EMAIL PROTECTED] writes: Unfortunately we can't just pstrdup because we have no pool to dup into. We could copy into a buffer on the stack... Again, this only affects already-ugly formats, so I see little problem with adding a copy penalty to *those* formats, as long as

Re: Incorrect if check in sockopt.c?

2002-05-24 Thread Jeff Trawick
Does somebody want to break the tie? (so far two alternate opinions of the same code, both indicating that there is a problem) -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...

Re: cvs commit: apr-util/strmatch apr_strmatch.c

2002-05-24 Thread Jeff Trawick
Jeff Trawick [EMAIL PROTECTED] writes: [EMAIL PROTECTED] writes: brianp 02/05/23 18:07:47 Modified:strmatch apr_strmatch.c Log: Switched to unsigned chars in the searching functions to avoid problems when input strings contain character values 127 Reported

Re: cvs commit: apr-util/strmatch apr_strmatch.c

2002-05-24 Thread Brian Pane
Jeff Trawick wrote: Jeff Trawick [EMAIL PROTECTED] writes: [EMAIL PROTECTED] writes: brianp 02/05/23 18:07:47 Modified:strmatch apr_strmatch.c Log: Switched to unsigned chars in the searching functions to avoid problems when input strings contain character values 127

Re: cvs commit: apr-util/strmatch apr_strmatch.c

2002-05-24 Thread Jeff Trawick
Brian Pane [EMAIL PROTECTED] writes: There's only one operation in the whole algorithm that really needs an unsigned char. I'll switch back to signed chars, with a cast to unsigned only in the case where the char value is used as an array index. excellent! -- Jeff Trawick | [EMAIL

Re: apr_date_parse_rfc segv

2002-05-24 Thread Cliff Woolley
On 24 May 2002, Jeff Trawick wrote: Unfortunately we can't just pstrdup because we have no pool to dup into. +1 The API needs to be changed to use const char * if at all possible. This isn't the first time this has come up. Already did that along with my commit yesterday. :) --Cliff