Re: apr_sha1

2004-12-07 Thread Joe Orton
On Tue, Dec 07, 2004 at 12:32:28PM +, Julian Foad wrote: > William A. Rowe, Jr. wrote: > >This simply isn't a good idea until 2.0. > > Does the project have a standard place to record proposed API changes for > the next major version so that they are not forgotten when that time comes? > If

Re: apr_sha1

2004-12-07 Thread William A. Rowe, Jr.
At 06:32 AM 12/7/2004, Julian Foad wrote: >William A. Rowe, Jr. wrote: >>This simply isn't a good idea until 2.0. > >Does the project have a standard place to record proposed API changes for the >next major version so that they are not forgotten when that time comes? If >not, may I suggest putti

Re: apr_sha1

2004-12-07 Thread Julian Foad
William A. Rowe, Jr. wrote: This simply isn't a good idea until 2.0. Does the project have a standard place to record proposed API changes for the next major version so that they are not forgotten when that time comes? If not, may I suggest putting this in the STATUS file under a heading like "F

Re: apr_sha1

2004-12-06 Thread William A. Rowe, Jr.
At 07:53 AM 12/5/2004, Joe Orton wrote: >On Sun, Dec 05, 2004 at 12:53:58PM +, Thom May wrote: > >You don't say which you propose to change, but either way it's an API >change not really worth bumping the major number for, I'd reckon. >There's an objection to making the md5 functions return vo

Re: apr_sha1

2004-12-05 Thread Joe Orton
On Sun, Dec 05, 2004 at 12:53:58PM +, Thom May wrote: > Guys, > any reason why apr_sha1_* are declared as void, and apr_md*_* are > apr_status_t? Any objections (I have patch plus tests ready to go) for > fixing this on HEAD? You don't say which you propose to change, but either way it's an AP

apr_sha1

2004-12-05 Thread Thom May
Guys, any reason why apr_sha1_* are declared as void, and apr_md*_* are apr_status_t? Any objections (I have patch plus tests ready to go) for fixing this on HEAD? -T

Re: cvs commit: apr-util/crypto apr_sha1.c

2001-01-19 Thread Greg Stein
> > gstein 01/01/19 01:19:53 > > > > Modified:crypto apr_sha1.c > > Log: > > add a missing type back in. this used to be AP_BYTE. > > > > Revision ChangesPath > > 1.22 +2 -0 apr-util/crypto/apr_s

RE: cvs commit: apr-util/crypto apr_sha1.c

2001-01-19 Thread William A. Rowe, Jr.
> gstein 01/01/19 01:19:53 > > Modified:crypto apr_sha1.c > Log: > add a missing type back in. this used to be AP_BYTE. > > Revision ChangesPath > 1.22 +2 -0 apr-util/crypto/apr_sha1.c Why? Please see apr.hw/apr.h.in.

RE: cvs commit: apr-util/include apr_base64.h apr_buckets.h apr_generic_hook.h apr_hooks.h apr_ring.h apr_sdbm.h apr_sha1.h apu.h.in apu.hw ap_base64.h ap_buckets.h ap_generic_hook.h ap_hooks.h ap_ring.h ap_sha1.h

2001-01-19 Thread William A. Rowe, Jr.
> wrowe 01/01/18 23:01:27 > > Modified:include apr_base64.h apr_buckets.h apr_generic_hook.h > apr_hooks.h apr_ring.h apr_sdbm.h apr_sha1.h > apu.h.in apu.hw > Removed: include ap_base64.h ap_buckets.h