[PATCH] some progress with apr_socket_data_get()/apr_socket_data_set()

2003-04-15 Thread Jeff Trawick
You may have known that socket data is implemented as pool userdata in a manner that prevented multiple sockets from the same pool being able to use the same key for socket data. Another problem is that any cleanup specified in the call to apr_socket_data_set() is run when the pool is cleaned

Re: HEAD and releases

2003-04-15 Thread William A. Rowe, Jr.
At 04:58 PM 4/15/2003, Joe Orton wrote: >Has 0.9.3 actually been released? I see the tag, but can't find tarballs >for it. Is it just waiting for someone to make tarballs? Sure, drop 'em in! The more hands the merrier (offers /me who has had about 5 spare cycles/hour just for recharging batterie

HEAD and releases

2003-04-15 Thread Joe Orton
Has 0.9.3 actually been released? I see the tag, but can't find tarballs for it. Is it just waiting for someone to make tarballs? Recently APR HEAD has been trying to keep backwards compatibility with 0.9.2, with the proviso that this will be dropped "for 1.0". It would seem sensible to allow HE

Re: [PATCH] hex format string for apr_uint64_t

2003-04-15 Thread Jeff Trawick
okay guys, what I just committed has #define APR_UINT64_T_HEX_FMT_LEN (sizeof(APR_UINT64_T_HEX_FMT) - 1) in apr.h*. What I think what everybody agrees is cool is to have these APR_foo_FMT_LEN symbols disappear with APR 1.0. I think Joe wanted to delete them ASAP and Bill wanted to mark them dep

Re: [PATCH] hex format string for apr_uint64_t

2003-04-15 Thread William A. Rowe, Jr.
At 03:22 PM 4/15/2003, Joe Orton wrote: >On Tue, Apr 15, 2003 at 04:15:32PM -0400, Jeff Trawick wrote: >> Joe Orton wrote: >> >On Tue, Apr 15, 2003 at 01:58:23PM -0400, Jeff Trawick wrote: >> >... >> > >> >>#define APR_UINT64_T_FMT_LEN 3 >> >>+#define APR_UINT64_T_HEX_FMT "llx" >> >>+#defin

Re: [PATCH] hex format string for apr_uint64_t

2003-04-15 Thread Jeff Trawick
Joe Orton wrote: On Tue, Apr 15, 2003 at 04:15:32PM -0400, Jeff Trawick wrote: Joe Orton wrote: On Tue, Apr 15, 2003 at 01:58:23PM -0400, Jeff Trawick wrote: ... #define APR_UINT64_T_FMT_LEN 3 +#define APR_UINT64_T_HEX_FMT "llx" +#define APR_UINT64_T_HEX_FMT_LEN 3 #define APR_TIME_T_FMT AP

Re: [PATCH] hex format string for apr_uint64_t

2003-04-15 Thread Joe Orton
On Tue, Apr 15, 2003 at 04:15:32PM -0400, Jeff Trawick wrote: > Joe Orton wrote: > >On Tue, Apr 15, 2003 at 01:58:23PM -0400, Jeff Trawick wrote: > >... > > > >>#define APR_UINT64_T_FMT_LEN 3 > >>+#define APR_UINT64_T_HEX_FMT "llx" > >>+#define APR_UINT64_T_HEX_FMT_LEN 3 > >>#define APR_TIM

Re: [PATCH] hex format string for apr_uint64_t

2003-04-15 Thread Jeff Trawick
Joe Orton wrote: On Tue, Apr 15, 2003 at 01:58:23PM -0400, Jeff Trawick wrote: ... #define APR_UINT64_T_FMT_LEN 3 +#define APR_UINT64_T_HEX_FMT "llx" +#define APR_UINT64_T_HEX_FMT_LEN 3 #define APR_TIME_T_FMT APR_INT64_T_FMT There's no need to add another _FMT_LEN #define, they are not rea

Re: [PATCH] hex format string for apr_uint64_t

2003-04-15 Thread Jeff Trawick
William A. Rowe, Jr. wrote: At 01:05 PM 4/15/2003, Jeff Trawick wrote: Jeff Trawick wrote: An unfortunately ugly example: apr_time_t now; apr_snprintf(..., "microsecs in hex: %" APR_UINT64_T_HEX_FMT, (apr_uint64_t)) err, that last line should be (apr_uint64_t)now) Of co

Re: [PATCH] hex format string for apr_uint64_t

2003-04-15 Thread Joe Orton
On Tue, Apr 15, 2003 at 01:58:23PM -0400, Jeff Trawick wrote: ... > #define APR_UINT64_T_FMT_LEN 3 > +#define APR_UINT64_T_HEX_FMT "llx" > +#define APR_UINT64_T_HEX_FMT_LEN 3 > #define APR_TIME_T_FMT APR_INT64_T_FMT There's no need to add another _FMT_LEN #define, they are not really nec

Re: [PATCH] hex format string for apr_uint64_t

2003-04-15 Thread William A. Rowe, Jr.
At 01:05 PM 4/15/2003, Jeff Trawick wrote: >Jeff Trawick wrote: >>An unfortunately ugly example: >> apr_time_t now; >> apr_snprintf(..., "microsecs in hex: %" APR_UINT64_T_HEX_FMT, >> (apr_uint64_t)) > >err, that last line should be > > (apr_uint64_t)now) Of course

apr_atomic_cas() interface

2003-04-15 Thread Jeff Trawick
why is it apr_uint32_t apr_atomic_cas(volatile apr_uint32_t *, long, long) (generic version) apr_uint32_t apr_atomic_cas(volatile apr_atomic_t *, apr_uint32_t, apr_uint32_t cmp) (MVS version) instead of apr_uint32_t apr_atomic_cas(volatile apr_uint32_t *, apr_uint32_t,

Re: [PATCH] hex format string for apr_uint64_t

2003-04-15 Thread Jeff Trawick
Jeff Trawick wrote: An unfortunately ugly example: apr_time_t now; apr_snprintf(..., "microsecs in hex: %" APR_UINT64_T_HEX_FMT, (apr_uint64_t)) err, that last line should be (apr_uint64_t)now)

[PATCH] hex format string for apr_uint64_t

2003-04-15 Thread Jeff Trawick
Hopefully there isn't a reason why this can't be implemented portably. Speak up quickly if you know of one :) Apache needs to format a 64-bit quantity in hex in a few places. Since hex formatting is typically supported for unsigned values only, the best compromise seems to be to have a format

Re: apr_generate_random_bytes() blocks forever

2003-04-15 Thread Ben Collins-Sussman
"David Reid" <[EMAIL PROTECTED]> writes: > Ben's point is more (I think) that if we say we're providing randomness then > we should provide that. But a caller isn't allowed to *explicitly* ask for poor-quality, non-blocking randomness? Why not? If the word "randomness" bothers people, then let

Re: apr_generate_random_bytes() blocks forever

2003-04-15 Thread David Reid
Ben's point is more (I think) that if we say we're providing randomness then we should provide that. Bear in mind that APR could be used for a lot of things, and having a potentially very weak random function isn't going to cut it in a lot of places. FWIW I've seen the sort of api that Ben alludes