[ 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
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,
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)
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
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
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
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...
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
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
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
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
11 matches
Mail list logo