apr_shm_calloc() segfaults if out of memory

2001-08-29 Thread Graham Leggett
Hi all, While testing some tolerances in the LDAP cache when it runs out of memory, I discovered that apr_shm_calloc() segfaults if you attempt to allocate a block of memory bigger than the memory block you orginally defined. Surely in this case apr_shm_calloc() should return NULL instead? Progr

Re: [PATCH] performance fix for time offset computation

2001-08-29 Thread Brian Pane
Roy T. Fielding wrote: On Wed, Aug 29, 2001 at 10:19:40AM -0400, Greg Marr wrote: At 10:05 AM 08/29/2001, William A Rowe wrote: At 07:36 PM 08/28/2001, Roy T. Fielding wrote: On Tue, Aug 28, 2001 at 03:16:42PM -0700, Brian Pane wrote: As far as I can tell, the result of the calculation should be in

Re: [PATCH] performance fix for time offset computation

2001-08-29 Thread Roy T. Fielding
On Wed, Aug 29, 2001 at 10:19:40AM -0400, Greg Marr wrote: > At 10:05 AM 08/29/2001, William A Rowe wrote: > >> At 07:36 PM 08/28/2001, Roy T. Fielding wrote: > >> >On Tue, Aug 28, 2001 at 03:16:42PM -0700, Brian Pane wrote: > >> > > As far as I can tell, the result of the calculation should be > >

Re: cvs commit: apr/file_io/win32 readwrite.c seek.c

2001-08-29 Thread Jeff Trawick
Jeff Trawick <[EMAIL PROTECTED]> writes: > I just started playing with /error/HTTP_NOT_FOUND.html.var at > OtherBill's suggestion. Even with this patch, the seek back to the end > of the de body is not going to the right place. > > gotta read some code... I know the patch is a big improvement a

Re: cvs commit: apr/file_io/win32 readwrite.c seek.c

2001-08-29 Thread Jeff Trawick
"Brian Havard" <[EMAIL PROTECTED]> writes: > On Wed, 29 Aug 2001 01:14:23 +1000 (EST), Brian Havard wrote: > > >On 28 Aug 2001 01:56:09 -, [EMAIL PROTECTED] wrote: > > > >>wrowe 01/08/27 18:56:09 > >> > >> Modified:file_io/win32 readwrite.c seek.c > >> Log: > >>Found a very ug

Re: [API PROPOSAL] apr_lock.h breakout of functionality, add cond vars

2001-08-29 Thread Justin Erenkrantz
On Wed, Aug 29, 2001 at 11:28:04AM -0700, Ryan Bloom wrote: > We should only keep both API's for the short term. Any API that we release > in a beta we need to support forever, so I am VERY much against releasing > a beta with the old locking API, because it is a very poor API. I have fundamental

Re: [API PROPOSAL] apr_lock.h breakout of functionality, add cond vars

2001-08-29 Thread Ryan Bloom
On Wednesday 29 August 2001 11:25, Justin Erenkrantz wrote: > On Wed, Aug 29, 2001 at 10:50:12AM -0700, Ryan Bloom wrote: > > My only other comment, is that while doing development, it would be > > REALLY cool if we could have access to both API's, which should end up > > pointing to the same imple

Re: [API PROPOSAL] apr_lock.h breakout of functionality, add cond vars

2001-08-29 Thread Justin Erenkrantz
On Wed, Aug 29, 2001 at 10:50:12AM -0700, Ryan Bloom wrote: > My only other comment, is that while doing development, it would be REALLY > cool if we could have access to both API's, which should end up pointing to > the same implementation. +1 *if* we keep both APIs. Otherwise, +0 - I'm not aga

Re: [API PROPOSAL] apr_lock.h breakout of functionality, add cond vars

2001-08-29 Thread Ryan Bloom
On Wednesday 29 August 2001 09:53, Aaron Bannert wrote: ++1. As I have said all along, the common function for all locks, was a point of contention between Manoj and I. I won, but I was wrong. It's time to fix that mistake. > Here are a few questions I have: > > 1) Do we also need these? I rea

[API PROPOSAL] apr_lock.h breakout of functionality, add cond vars

2001-08-29 Thread Aaron Bannert
The following is a proposed API change to the apr_lock.h interface. It basicly breaks out the lock types into the 4 main types, then adds condition variables. I'd like to stimulate some discussion on this topic, and get some +1's to proceed with the proposal (or parts of it at least): - thread mut

Re: [proposal] DBM - allow multiple DBM's of differnt types at the same time. -- V2

2001-08-29 Thread Ian Holsman
On Sun, 2001-08-26 at 01:52, Greg Stein wrote: > On Sat, Aug 25, 2001 at 06:27:23PM -0700, Ian Holsman wrote: > > does anyone have any objections to this? > > all it is really doing is removing the MACRO definitions > > and splitting up the apr_dbm into 4 files (a interface, and 3 > > implementati

[Nicolas.Williams@ubsw.com: Re: Interposing LSA functions (was: RE: [pamldap] PAM for Windows NT/2000)]

2001-08-29 Thread Luke Kenneth Casson Leighton
- Forwarded message from Nicolas Williams <[EMAIL PROTECTED]> - Delivered-To: [EMAIL PROTECTED] Date: Wed, 29 Aug 2001 10:26:47 -0400 From: Nicolas Williams <[EMAIL PROTECTED]> To: Luke Kenneth Casson Leighton <[EMAIL PROTECTED]>, Luke Howard <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTE

Re: [PATCH] performance fix for time offset computation

2001-08-29 Thread Greg Marr
At 10:05 AM 08/29/2001, William A Rowe wrote: > At 07:36 PM 08/28/2001, Roy T. Fielding wrote: > >On Tue, Aug 28, 2001 at 03:16:42PM -0700, Brian Pane wrote: > > > As far as I can tell, the result of the calculation should be > > > independent of daylight savings (e.g., always 5 for US/Eastern). >

Re: Interposing LSA functions (was: RE: [pamldap] PAM for Windows NT/2000)

2001-08-29 Thread Luke Kenneth Casson Leighton
On Wed, Aug 29, 2001 at 08:45:39PM +1000, Luke Howard wrote: > > The URL: > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/hh/secpack/customsecfunctions_9js1.asp > > is worth a look as it describes the API used to retrieve the > authorization data for a user and crea

Re: [PATCH] performance fix for time offset computation

2001-08-29 Thread Greg Marr
At 07:36 PM 08/28/2001, Roy T. Fielding wrote: On Tue, Aug 28, 2001 at 03:16:42PM -0700, Brian Pane wrote: > As far as I can tell, the result of the calculation should be > independent of daylight savings (e.g., always 5 for US/Eastern). Then the calculation must be wrong, since EDT is -0400. EST