Ok...
I got it compiling and it brings up a test page now in Win32
(with the following patch applied)
I put the APR_MEM_PSTRDUP into apr_private.h, and fixed up the .dsp's
to include a memory subfolder.
..Ian
> -Original Message-
> From: Ian Holsman [mailto:[EMAIL PROTECTED]
> Sent: Tues
On Tue, Jun 05, 2001 at 04:15:29PM -0400, Cliff Woolley wrote:
> On Tue, 5 Jun 2001, dean gaudet wrote:
>
> > this would seem like an OK time to change the function name to something
> > more in line with other names in ap/apr... such as ap_parse_http_date.
> > (but include a comment indicating th
Could be!
david
- Original Message -
From: "Ben Laurie" <[EMAIL PROTECTED]>
To:
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, June 05, 2001 7:23 PM
Subject: Re: cvs commit: apr/locks/unix locks.c
> Isn't this another example where we should just die instead of returning
> an error?
>
> Cheers
From: "Cliff Woolley" <[EMAIL PROTECTED]>
Sent: Tuesday, June 05, 2001 12:36 PM
> > Yes, maybe the "no checking" isn't documented, but it has been policy for a
> > long while. Yes, we *should* document it. Nobody has got around to it is
> > all. I'm surprised that you aren't familiar with it.
>
On Tue, 5 Jun 2001, Ben Laurie wrote:
> >apr_status_t apr_os_lock_put(apr_lock_t **lock, apr_os_lock_t *thelock,
> > apr_pool_t *pool)
> >{
> > -if (cont == NULL) {
> > +if (pool == NULL) {
> >return APR_ENOPOOL;
> >}
> >
hi.
no idea when this stopped working on win32
the macro APR_MEM_PSTRDUP (in acconfig.h) also needs to be defined in win32
somewhere..
but I'm not sure where this should go (maybe apr_private.h ???)
--
Ian Holsman
Performance Measurement & Analysis
415-364-8608
sms.patch
Description: Binary
On 5 Jun 2001 [EMAIL PROTECTED] wrote:
> As discussed on [EMAIL PROTECTED] - add a comment about the assert/checking
> input debate. Our policy is "don't check input values." Feel free
> to change the wording. It's something, but we've had two longish
> threads in the last day about thi
Justin Erenkrantz wrote:
>
> On Tue, Jun 05, 2001 at 01:54:05AM +0200, Sander Striker wrote:
> > Hi,
> >
> > This patch adds HMAC MD5 to apr-util.
>
> Where would we use this? Is this algorithm of sufficient usage that it
> would benefit being in apr-util? I've never heard of HMAC before - I
>
Justin Erenkrantz wrote:
> My argument is that I don't like having production code differ from
> debug code AT ALL. I want the debug builds to behave almost
> exactly like the release builds. IMHO, the differences are the
> compiler optimizations, symbols and debugging information that the
> comp
Isn't this another example where we should just die instead of returning
an error?
Cheers,
Ben.
[EMAIL PROTECTED] wrote:
>
> dreid 01/06/05 06:48:28
>
> Modified:locks/unix locks.c
> Log:
> One slipped through the rename, but got it now!
>
> Revision ChangesPath
> 1.5
On Tue, Jun 05, 2001 at 10:46:52AM -0700, [EMAIL PROTECTED] wrote:
> If I can suggest a place, the Web site. We already have a page about "How
> to contribute code", so just add it to that page.
If no one beats me to it, I'll look at adding this in the next few days.
Now that I know how to update
On Tue, 5 Jun 2001, Cliff Woolley wrote:
> On Tue, 5 Jun 2001, Greg Stein wrote:
>
> > Ease up, David. Cliff did the right thing here.
>
> We all just got a little worked up, I think. No harm done. Case closed.
>
> > Yes, maybe the "no checking" isn't documented, but it has been policy for a
> >
Oh, geez.
This is really ugly. It is creating dual paths all over. And the lock
structure now has a couple variants that need to be checked/tested.
Why can't we have a new pool type? The pool structure is now private (I made
it private about a month ago). We can change bits under the covers pret
On Tue, 5 Jun 2001, Greg Stein wrote:
> Ease up, David. Cliff did the right thing here.
We all just got a little worked up, I think. No harm done. Case closed.
> Yes, maybe the "no checking" isn't documented, but it has been policy for a
> long while. Yes, we *should* document it. Nobody has g
Ease up, David. Cliff did the right thing here.
Yes, maybe the "no checking" isn't documented, but it has been policy for a
long while. Yes, we *should* document it. Nobody has got around to it is
all. I'm surprised that you aren't familiar with it.
Cheers,
-g
On Tue, Jun 05, 2001 at 09:23:08AM
On 5 Jun 2001 [EMAIL PROTECTED] wrote:
> --- apr.h.in2001/05/10 18:09:26 1.80
> +++ apr.h.in2001/06/05 08:15:05 1.81
> @@ -174,6 +174,8 @@
>typedef @off_t_value@ apr_off_t;
>typedef @socklen_t_value@ apr_socklen_t;
>
> +typedef struct apr_l
On Tue, 5 Jun 2001, David Reid wrote:
> > * Remove the unnecessary parameter checks and the extra error codes that
> > went along with them. The APR policy is to segfault on a NULL
> > parameter
> > rather than silently returning some error code that the caller might
> > not che
> * Remove the unnecessary parameter checks and the extra error codes that
> went along with them. The APR policy is to segfault on a NULL
parameter
> rather than silently returning some error code that the caller might
> not check anyway.
Can't say I agree 100% with this, but if yo
> On Tue, Jun 05, 2001 at 01:54:05AM +0200, Sander Striker wrote:
> > Hi,
> >
> > This patch adds HMAC MD5 to apr-util.
>
> Where would we use this? Is this algorithm of sufficient usage that it
> would benefit being in apr-util? I've never heard of HMAC before - I
> had to look it up on rfc-ed
On Tue, Jun 05, 2001 at 01:54:05AM +0200, Sander Striker wrote:
> Hi,
>
> This patch adds HMAC MD5 to apr-util.
Where would we use this? Is this algorithm of sufficient usage that it
would benefit being in apr-util? I've never heard of HMAC before - I
had to look it up on rfc-editor.org. Maybe
[EMAIL PROTECTED] gstein]$ ssh dev.apache.org
...
[EMAIL PROTECTED] gstein]$ cd /www/apr.apache.org/
[EMAIL PROTECTED] apr.apache.org]$ cvs up
Any APR committer should have privs to do that. If not, then it is a goof on
the perms in /www/apr.apache.org which needs to be fixed. Speak up here, and
w
Hi,
I failed to say that I found Justins view of things
(although lengthy... :-) ...like the question :-)
insightfull. At least now I know how he came to
adopt this view. I reckon the rest of you opposing
null asserts share this view.
Sander
Hi,
> Okay, let me clarify my position on this. I apologize for being
> quasi-abrupt earlier.
No prob.
[...]
> As far as a policy goes, I'm not sure of an official one. Since APR is
> essentially branched from httpd, it really follows httpd policy. AFAIK,
> httpd has always had this policy.
23 matches
Mail list logo
