APR_0_9_BRANCH and APU_0_9_BRANCH are the branch tags.
Max Bowsher wrote:
On Tue, 2 Sep 2003, Jeff Trawick wrote:
somebody want to sanity check this before I screw everything up?
$ cd apr
$ cvs tag -b -r HEAD -R APR_0_9_X
$ cd ../apr-util
$ cvs tag -b -r HEAD -R APR_0_9_X
Previous apr-util tags have used the prefix "APU_", not "APR_".
thanks for catch
In the case that a server is running out of memory (yeah, I know it never happens),
apr_allocator_alloc() is returning NULL, but it is never checked for in apr_bucket_alloc().
Does the bucket alloc function should pass that NULL back to the
function/application asking for memory?
Thanks,
JJ
Other outstanding issues that IMHO can/should be fixed in 1.0.
Configure issues:
1) dealing with APR_HAS_LARGE_FILES on linux
http://marc.theaimsgroup.com/?l=apr-dev&m=105277560530754&w=2
Currently it's just disabled, even when available.
the whole thread is here:
http://marc.theaimsgroup.com/?t=10
This is another patch that resulted from
http://marc.theaimsgroup.com/?l=apr-dev&m=101223985500849&w=2
but was never commented on/committed
Stas Bekman wrote:
this patch makes sure that apr_date_parse_rfc doesn't corrupt the
callers date string.
it was discussed in this thread:
http://marc.theai
[X] - Yes, I think we're ready for 1.0 now (in both apr and apr-util)
[ ] - No, I think we're not ready for 1.0 because __
Cliff Woolley wrote:
On Tue, 2 Sep 2003, Jeff Trawick wrote:
somebody want to sanity check this before I screw everything up?
$ cd apr
$ cvs tag -b -r HEAD -R APR_0_9_X
$ cd ../apr-util
$ cvs tag -b -r HEAD -R APR_0_9_X
Looks basically right to me. Nits: If you're already up-to-date with
HEAD, y
anybody cares to comment on this?
I have worked around this, doing:
#include "apr_hooks.h"
static void extra_apr_init(void)
{
if (apr_hook_global_pool == NULL) {
apr_pool_t *global_pool;
apr_status_t rv = apr_pool_create(&global_pool, NULL);
if (rv != APR_SUCCESS) {
On Tue, 2 Sep 2003, Jeff Trawick wrote:
>
> somebody want to sanity check this before I screw everything up?
>
> $ cd apr
> $ cvs tag -b -r HEAD -R APR_0_9_X
> $ cd ../apr-util
> $ cvs tag -b -r HEAD -R APR_0_9_X
Previous apr-util tags have used the prefix "APU_", not "APR_".
Max.
+1
Sander Striker wrote:
>
> > From: Cliff Woolley [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, September 02, 2003 9:52 PM
>
> > On Tue, 2 Sep 2003, Jeff Trawick wrote:
> > Looks basically right to me. Nits: If you're already up-to-date with
> > HEAD, you don't have to specify -r HEAD. And if
> From: Cliff Woolley [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 02, 2003 9:52 PM
> On Tue, 2 Sep 2003, Jeff Trawick wrote:
>> somebody want to sanity check this before I screw everything up?
>>
>> $ cd apr
>> $ cvs tag -b -r HEAD -R APR_0_9_X
>> $ cd ../apr-util
>> $ cvs tag -b -r HEAD
On Tue, 2 Sep 2003, Jeff Trawick wrote:
> somebody want to sanity check this before I screw everything up?
>
> $ cd apr
> $ cvs tag -b -r HEAD -R APR_0_9_X
> $ cd ../apr-util
> $ cvs tag -b -r HEAD -R APR_0_9_X
Looks basically right to me. Nits: If you're already up-to-date with
HEAD, you don't
Justin Erenkrantz wrote:
--On Tuesday, September 02, 2003 13:46:43 -0400 Jeff Trawick
<[EMAIL PROTECTED]> wrote:
I would suggest that a 0.9 branch be created from HEAD ASAP for use by
Apache 2.0.x and any other apps that have to maintain a certain API, then
we have 7 days to make the changes that
hey Bill,
> > Please correct me if i'm wrong, but to my understanding, the
TransmitFile()
> > call is run in overlapped mode, hence transmitfile() returns almost
> > immediatly and only blocks on the WaitForSingleObject() call. Handling
> > timeouts, doesnt work any differently with this than befo
--On Tuesday, September 02, 2003 13:46:43 -0400 Jeff Trawick
<[EMAIL PROTECTED]> wrote:
I would suggest that a 0.9 branch be created from HEAD ASAP for use by
Apache 2.0.x and any other apps that have to maintain a certain API, then
we have 7 days to make the changes that were held back until jus
Justin Erenkrantz wrote:
I'd like to propose a vote:
[ ] - Yes, I think we're ready for 1.0 now (in both apr and apr-util)
[X] - No, I think we're not ready for 1.0 because __
...there are some trivial things to change prior to 1.0 API freeze, such
as moving sockaddr_in* to end of apr_sock
Maarten Bekers wrote:
hi,
Maarten,
How do you propose to handle Timeout processing with your patch?
Please correct me if i'm wrong, but to my understanding, the TransmitFile()
call is run in overlapped mode, hence transmitfile() returns almost
immediatly and only blocks on the WaitForSingleObject
On Tue, 2 Sep 2003, Balazs Mezodi wrote:
> i'm new to apr, so i don't know if i ask this question at the right
> place...
Indeed it is.
> how to use apr_reslist with sockets correctly? sockets are "fragile",
> therefore error handling is very important:
Hah, that's a good question. As far
hi,
> Maarten,
> How do you propose to handle Timeout processing with your patch?
Please correct me if i'm wrong, but to my understanding, the TransmitFile()
call is run in overlapped mode, hence transmitfile() returns almost
immediatly and only blocks on the WaitForSingleObject() call. Handling
At 07:28 PM 9/1/2003, Justin Erenkrantz wrote:
>> Brian Pane wrote:
>>
>> Here's my attempt at summarizing all the proposals.
>> There was a lot of debate about the naming of the time
>> type--whether it was good or bad to give it a name so
>> similar to time_t, whether the type name should reflect
Colm MacCarthaigh wrote:
On Mon, Aug 25, 2003 at 12:19:27PM -0400, Jeff Trawick wrote:
If getaddrinfo() returns IPv6 addresses larger
than that, we're hosed at that point and shouldn't be copying into the
apr_sockaddr_info_t anyway.
We get away with it, just about. Allthough the full length is
c
On Mon, Sep 01, 2003 at 05:41:45PM -0700, Justin Erenkrantz wrote:
> Joe Orton wrote:
> > ...
> >> +#ifdef SIN6_LEN
> >> +sa.sin_len = sizeof(sa);
> >> +#endif
> > ...
> >
> > Is this bit needed? It causes false negatives on some BSD platforms:
> >
> > configure:20070: checking whether ge
hi,
i'm new to apr, so i don't know if i ask this question at the right
place...
i'm using the apr which is bundled with apache-2.0.47.
how to use apr_reslist with sockets correctly? sockets are "fragile",
therefore error handling is very important:
in apr-util/misc/apr_reslist.c the f
On Mon, Sep 01, 2003 at 05:41:45PM -0700, Justin Erenkrantz wrote:
> What are our options here? This exact same code appears in the
> getnameinfo() check (APR_CHECK_WORKING_GETNAMEINFO).
Yeah, but there sa is struct sockaddr_in. SIN6 is just a useful
macro guaranteed to be defined on systems wh
Joe Orton wrote:
> ...
>> +#ifdef SIN6_LEN
>> +sa.sin_len = sizeof(sa);
>> +#endif
> ...
>
> Is this bit needed? It causes false negatives on some BSD platforms:
>
> configure:20070: checking whether getnameinfo resolves IPv4-mapped IPv6
> addresses
> configure:20131: gcc -o conftest -g -
> Brian Pane wrote:
>
> Here's my attempt at summarizing all the proposals.
> There was a lot of debate about the naming of the time
> type--whether it was good or bad to give it a name so
> similar to time_t, whether the type name should reflect
> an implementation like binary microseconds, etc.
> Depending on just how hastily you want to tag a release,
> I'd like to clean up the apr_atomic API prior to 1.0.
Personally, I'd like to see the first APR 1.0 release candidate out by the
end of this week. At that point, I'd like to see whatever API is included
in there frozen for 1.0 (barring
27 matches
Mail list logo
