Re: cvs commit: apr/network_io/unix sendrecv.c

2002-05-17 Thread Justin Erenkrantz
On Fri, May 17, 2002 at 05:33:11PM -0400, Greg Ames wrote: > [EMAIL PROTECTED] wrote: > > > FreeBSD sendfile: return an error if the kernel returns 0 & no bytes sent. > > This probably means the file became smaller after it was stat()ed. > > While testing this on daedalus, I noticed yet anoth

Re: cvs commit: apr/network_io/unix sendrecv.c

2002-05-17 Thread Greg Ames
[EMAIL PROTECTED] wrote: > FreeBSD sendfile: return an error if the kernel returns 0 & no bytes sent. > This probably means the file became smaller after it was stat()ed. While testing this on daedalus, I noticed yet another sendfile_it_all assert dump in /tmp, dated May 10. I think I'll put

Re: cvs commit: apr/strings apr_cpystrn.c

2002-05-17 Thread William A. Rowe, Jr.
At 10:27 AM 5/17/2002, you wrote: Ben Laurie <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: > > > > trawick 02/05/17 07:58:27 > > > > Modified:strings apr_cpystrn.c > > Log: > > don't check for malloc() failure in our strdup() replacement > > E - why not? we're going to g

Re: APR_XtOffsetOf -> APR_OFFSETOF about to happen

2002-05-17 Thread Aaron Bannert
On Fri, May 17, 2002 at 03:51:13PM -0400, Cliff Woolley wrote: > > OtherBill's recent commit reminded me that I never got around to following > up on http://marc.theaimsgroup.com/?l=apr-dev&m=101647219122386&w=2, > wherein we decided that it was okay for APR_XtOffsetOf to get renamed to > APR_OFFS

APR_XtOffsetOf -> APR_OFFSETOF about to happen

2002-05-17 Thread Cliff Woolley
OtherBill's recent commit reminded me that I never got around to following up on http://marc.theaimsgroup.com/?l=apr-dev&m=101647219122386&w=2, wherein we decided that it was okay for APR_XtOffsetOf to get renamed to APR_OFFSETOF. I've made all the changes and will commit them. My only question

Re: #define APR_WANT_MEMFUNC

2002-05-17 Thread Cliff Woolley
On Fri, 17 May 2002 [EMAIL PROTECTED] wrote: > There is a: > > #define APR_WANT_MEMFUNC > > This seems to interact with the above; i.e. when you do not get apr_pools > in early enough. Is this avoidable; can we warn for this ? I'm not sure I understand what the problem is. Is there a part

#define APR_WANT_MEMFUNC

2002-05-17 Thread dirkx
There is a: #define APR_WANT_MEMFUNC in both apr_allocators and apr_pools. Both apr_pools and apr_thread* get included from various places. Once they are included their _H sentiniel is defined; making sure they are never included again. This seems to interact with the above; i.e. when y

Re: cvs commit: apr/network_io/unix sendrecv.c

2002-05-17 Thread Greg Ames
[EMAIL PROTECTED] wrote: > linux sendfile: exit with an error if the file gets smaller in the middle > of > a request. btw, thanks Justin for analysing the dump from the new trap on daedalus. Greg

Incorrect if check in sockopt.c?

2002-05-17 Thread Justin Erenkrantz
Please see apr/network_io/unix/sockopt.c line 214. The comment above that check says: /* must disable the incomplete read support if we change to a * blocking socket. */ if (on == 0) { ...disable incomplete reads... } But, if on == 0, we're a non-blocking socket (timeout value of 0 implies

Re: cvs commit: apr/strings apr_cpystrn.c

2002-05-17 Thread Jeff Trawick
Ben Laurie <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: > > > > trawick 02/05/17 07:58:27 > > > > Modified:strings apr_cpystrn.c > > Log: > > don't check for malloc() failure in our strdup() replacement > > E - why not? we're going to get segfaults inside strdup()

Re: cvs commit: apr/strings apr_cpystrn.c

2002-05-17 Thread Ben Laurie
[EMAIL PROTECTED] wrote: > > trawick 02/05/17 07:58:27 > > Modified:strings apr_cpystrn.c > Log: > don't check for malloc() failure in our strdup() replacement E - why not? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limi

Re: cvs commit: apr/strings apr_cpystrn.c

2002-05-17 Thread Aaron Bannert
>size_t len = strlen(str) + 1; > >if (!(sdup = (char *) malloc(len))) { > -/* ### whoops! we can't call Apache logging routines here... */ > -#if 0 > -apr_log_error(APLOG_MARK, APLOG_STARTUP | APLOG_NOERRNO, 0, NULL, > - "Ouch! Out of