RE: [PATCH] apr_pools.c patch for bounds checking compiler

> From: Blair Zajac [mailto:[EMAIL PROTECTED] > Sent: 06 August 2002 19:53 > Sander Striker wrote: >>> Blair Zajac wrote: I'm using the bounds checking gcc 3.1.1 to check for memory issues in Apache and Subversion. This patch to gcc compiles the code with extra checks for illegal

Re: [PATCH] apr_pools.c patch for bounds checking compiler

Sander Striker wrote: > > > From: Blair Zajac [mailto:[EMAIL PROTECTED] > > Sent: 01 August 2002 01:10 > > > Blair Zajac wrote: > >> > >> I'm using the bounds checking gcc 3.1.1 to check for memory issues > >> in Apache and Subversion. This patch to gcc compiles the code with > >> extra checks f

Re: [PATCH] win32 sendrecv.c cleanup

After taking a closer look at the code, I think all that really needs to be done is to fall back to a malloc() if _alloca() fails. I don't know the conditions that would cause _alloca() to fail on Win32 but falling back to a malloc() should work for both platforms even though it may never be ca

Re: [PATCH] win32 sendrecv.c cleanup

Yes, I sometimes forget that, and certainly we can ifdef it. One old question ... did 4kb make sense for the sendfile header/trailers vector? The new question ... is it large enough to concern you, and would it make sense to use another granularity on Netware (1kb, 2kb?) Letting the sendv logic

Re: [PATCH] win32 sendrecv.c cleanup

Bill, NetWare takes advantage of the Win32 Network_io code since we are also on Winsock. Allocating off of the stack may cause a problem for us since NetWare has a fixed size stack. Can the orginal code be #ifdef'd for NETWARE? Brad Brad Nicholes Senior Software Engineer Novell, Inc., the

RE: [PATCH] win32 sendrecv.c cleanup

+1 > Folks, > > Please review the attached patch that eliminates the rather > nasty allocations > that can occur in two situations. One is in apr_sendv() when we > have more than > 50 items, now simply allocate the vectors on the stack [very > portable across > win32, from vc5 onwards.] Th

[PATCH] win32 sendrecv.c cleanup

Folks, Please review the attached patch that eliminates the rather nasty allocations that can occur in two situations. One is in apr_sendv() when we have more than 50 items, now simply allocate the vectors on the stack [very portable across win32, from vc5 onwards.] The other simply allocates

Report of something very similar to the Win32 bug?

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9557 Seems remarkably like what I observed tonight with the hdtr bug just fixed in cvs for network_io/win32/sendrecv.c ... but on BSD. Perhaps a BSD hacker would care to take a look at the bug on Win32 and this report? Bill

Re: [PATCH] poll.c:apr_pollset_poll()

Thanks for the fix. I just committed it. Brian Rob Saccoccio wrote: The descriptors return value for apr_pollset_poll() isn't setup in the !HAVE_POLL path.. --rob diff -u -r1.26 poll.c --- poll.c 4 Aug 2002 04:43:23 - 1.26 +++ poll.c 6 Aug 2002 01:18:17 - @@ -602,6 +624,7 @

Re: [PATCH] pollacc.c poll.c

Rob Saccoccio wrote: I like the concept, but... +else if (aprset[i].desc_type == APR_NO_DESC) { +pollset[i].fd = -1; +continue; I'm not sure if it's safe to have an fd of -1 in the pollset. I don't know if its portable but its the right approach on S

Re: apr_pollset API

Rob Saccoccio wrote: The pollset API seems to be missing something... create a pollset with size 100 add 50 descriptors call poll() If poll returns with 20 descriptors ready, I can't traverse the 20 ready descriptors because they're scattered over an array of 50. No, they're the first 20 in the

apr_pollset API

The pollset API seems to be missing something... create a pollset with size 100 add 50 descriptors call poll() If poll returns with 20 descriptors ready, I can't traverse the 20 ready descriptors because they're scattered over an array of 50. This means I have to traverse the whole 100 (wh

[PATCH] poll.c:apr_pollset_poll()

The descriptors return value for apr_pollset_poll() isn't setup in the !HAVE_POLL path.. --rob diff -u -r1.26 poll.c --- poll.c 4 Aug 2002 04:43:23 - 1.26 +++ poll.c 6 Aug 2002 01:18:17 - @@ -602,6 +624,7 @@ } } +*descriptors = pollset->result_set;

RE: [PATCH] pollacc.c poll.c

> I like the concept, but... > > >+else if (aprset[i].desc_type == APR_NO_DESC) { > >+pollset[i].fd = -1; > >+continue; > > > > I'm not sure if it's safe to have an fd of -1 in the pollset. I don't know if its portable but its the right approach on Solaris: If

Re: [PATCH] pollacc.c poll.c

Rob Saccoccio wrote: The following patch to HEAD corrects problems with the transparent poll API. Currently, the apr_poll_t struct is handled ambiguously WRT whether its entries are packed or sparse. The brokeness has probably not been apparent because in httpd entries are never removed. I like th