Re: cvs commit: apr-util/include apr_hooks.h

ben 01/01/24 14:52:57 Modified:server config.c hooksapr_hooks.c include apr_hooks.h Log: The current hooking module is _not_ a debugging aid. that's fine ... I just hope you grepped for all occurances ... I normalized two variations

Introducing me.

Greetings, all. Mike Pilato here, Subversion developer, and first- time APR list poster. I've found some bugs in the APR code that only show up in Windows 95 and 98, so I plan to submit a few patches in the very (perhaps even very *very*) near future. Anything you might care to know about me

[patch] GP Fault on CreateFileA() call.

* open.c (apr_open): Fixed deferencing of potentially NULL pointer (and incorrect logic, at any rate) in call to CreateFileA( ). Index: open.c === RCS file:

Re: Introducing me.

Welcome Mike. :-) I am sure I speak for everybody here when I say we are very glad you have come to the party, and we look forward to your patches. Ryan On 25 Jan 2001 [EMAIL PROTECTED] wrote: Greetings, all. Mike Pilato here, Subversion developer, and first- time APR list poster. I've

[patch] Use of MoveFileEx() (unsupported in Win95/98)

Hoping that cvs diff -u is all I need to do to create unified diffs... * open.c (apr_rename_file): Replaced use of unsupported function MoveFileEx() with MoveFile() for pre-Windows NT (Win95/98) OS levels. This

Re: [patch] Use of MoveFileEx() (unsupported in Win95/98)

On 25 Jan 2001 [EMAIL PROTECTED] wrote: Hoping that cvs diff -u is all I need to do to create unified diffs... That's it. Thanks for the unified diff, it makes it much easier to review the patch. :-) Ryan ___ Ryan

Re: [PATCH] ap_brigade_partition()

--- Greg Stein [EMAIL PROTECTED] wrote: Now that we're actually using this function, I figured it was time to dig in and spend the time with this patch. :-) Cool. Just so you know, I've been kind of out-of-touch with the list for a while, since the 1000+ messages that accumulated while I was

Re: [PATCH] allocate properly-sized buffer for header

Can you put in words and some simple examples what's wrong with the API? The problem is that it is impossible to do a lot of small writes to a brigade efficiently. Take as an example, code that needs to add 20 five byte buffers to brigade. There are two options: 1) bigbuff =

Re: [PATCH] allocate properly-sized buffer for header

The problem is that it is impossible to do a lot of small writes to a brigade efficiently. Take as an example, code that needs to add 20 five byte buffers to brigade. There are two options: 1) bigbuff = apr_pstrcat(p, buf1, buf2, buf3, buf4, buf5, ...); b =

[PATCH] brigade buffering.

This general patch has been on new-httpd, but it really belongs here. This is my general concept for how brigades should be buffered. There are some bugs here, and it is not a full solution. These are basically meant as underlying functions, programs such as Apache would need to put wrappers

Re: [PATCH] allocate properly-sized buffer for header

Why write to the brigade instead of the top filter? Because we aren't always writing to the top filter. Sometimes, we are writing to a lower filter. This is the problem with current implementation. I meant the top from the perspective of the writer (i.e., a lower filter only knows about

Re: [PATCH] allocate properly-sized buffer for header

The problem with this type of optimization is that the brigade code cannot know the optimal size of a bucket -- only the next filter in the chain can know, since what is optimal will depend on what kind of processing is done next. However, the programmer knows what kind of data

Re: [PATCH] brigade buffering.

At 03:41 PM 01/25/2001, [EMAIL PROTECTED] wrote: This general patch has been on new-httpd, but it really belongs here. This is my general concept for how brigades should be buffered. FYI: this has the potential to fail miserably: char buffer[APR_BUCKET_BUFF_SIZE + 1]; int i; for(i =

Re: [PATCH] brigade buffering.

At 03:41 PM 01/25/2001, [EMAIL PROTECTED] wrote: This general patch has been on new-httpd, but it really belongs here. This is my general concept for how brigades should be buffered. FYI: this has the potential to fail miserably: char buffer[APR_BUCKET_BUFF_SIZE + 1]; int i;

Re: [PATCH] brigade buffering.

At 04:51 PM 01/25/2001, [EMAIL PROTECTED] wrote: FYI: this has the potential to fail miserably: I need to think about these, but I think you are correct. I can provide a walk-through of the code if you want. I decided it was too long to post to the list. I am not proposing that this is

Re: [PATCH] brigade buffering.

However, you are correct that in general this is an issue, the solution is to always copy the data, but that has other drawbacks. So, there are two answers to this that I see. #1, tell the programmer that (s)he is out of luck if (s)he doesn't understand the code. #2, actually copy all

Re: [PATCH] brigade buffering.

At 06:09 PM 01/25/2001, [EMAIL PROTECTED] wrote: So, there are two answers to this that I see. #1, tell the programmer that (s)he is out of luck if (s)he doesn't understand the code. #2, actually copy all the data. So then the rule has to be that if call a apr_brigade_* function that can