Following some discussion at the hackathon today and previous discussions
on this list, a new 1.0 branch has been created. This will be used for
what will hopefully be an imminent APR 1.0 release!
Discussions over the course of today among several APR developers it
became apparent that the Ben
This patch adds support for sha1 to apr_password_validate.
Tested with httpd-2.1 head and mod_authn_file. Without this patch, htpasswd
can write out sha1 encoded passwords, but none of the authentication modules
could use sha1 encoded passwords.
It seems like sha1 support was always intended to
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
[EMAIL PROTECTED] wrote:
Following some discussion at the hackathon today and previous discussions
on this list, a new 1.0 branch has been created. This will be used for
what will hopefully be an imminent APR 1.0 release!
After the race conditions in the Win32 condition variables are fixed, I
--On Saturday, November 15, 2003 9:19 PM -0700 Paul Querna
[EMAIL PROTECTED] wrote:
This patch adds support for sha1 to apr_password_validate.
You win the lucky prize for the day. ;-) Committed. (Jeff and I went,
'Sure, looks fine.')
Perhaps this should also be applied to the 0.9 branch?
We
this will resolve two types of problems:
1) all implementations will then be required to use a single set of function
prototypes, avoiding some problems we've had getting all platform logic to
agree on what the prototype should be
2) allow bug fixes to atomic code without rebuilding
On Sun, Nov 16, 2003 at 03:05:59PM -0500, Jeff Trawick wrote:
this will resolve two types of problems:
1) all implementations will then be required to use a single set of
function prototypes, avoiding some problems we've had getting all platform
logic to agree on what the prototype should
Aaron Bannert wrote:
On Sun, Nov 16, 2003 at 03:05:59PM -0500, Jeff Trawick wrote:
this will resolve two types of problems:
1) all implementations will then be required to use a single set of
function prototypes, avoiding some problems we've had getting all platform
logic to agree on what the
This was discussed previously in the thread request for comments: new atomic
API but the thread died out.
I'm not about to jump on this because of lack of mojo to get the various
platform-specific bits to work, but I'm willing to teach the z/OS code to
conform if Greg doesn't beat me to it.
On Sun, Nov 16, 2003 at 03:13:21PM -0500, Jeff Trawick wrote:
+1 This is great, but will having to call a function negatively affect
performance?
Of course :) Pick your poison.
Hmm...maybe we should compare performance of a functionized version
of atomics vs. doing the same using pthread
Aaron Bannert wrote:
On Sun, Nov 16, 2003 at 03:13:21PM -0500, Jeff Trawick wrote:
+1 This is great, but will having to call a function negatively affect
performance?
Of course :) Pick your poison.
Hmm...maybe we should compare performance of a functionized version
of atomics vs. doing the same
I've updated the tools/release.sh script in the apr-dist CVS repository
to make it easier for anyone to create APR tarballs. Before it was
necessary for a tag to exist before a tarball could be created. This
made it very difficult to release experimental/developmental tarballs
to a set of users
--On Sunday, November 16, 2003 8:37 PM + [EMAIL PROTECTED] wrote:
aaron 2003/11/16 12:37:07
Modified:toolsrelease.sh
Log:
It now takes a CVS TAG *and* a RELEASE_VERSION.
The TAG is what we pull from CVS.
The RELEASE_VERSION is what we call the tarball.
As I said in
Why not get apr_atomic_cas32 to work everywhere and have portable functions
that use that?
On Sun, Nov 16, 2003 at 03:19:42PM -0800, Justin Erenkrantz wrote:
--On Sunday, November 16, 2003 8:37 PM + [EMAIL PROTECTED] wrote:
aaron 2003/11/16 12:37:07
Modified:toolsrelease.sh
Log:
It now takes a CVS TAG *and* a RELEASE_VERSION.
The TAG is what we pull
Ok, I can't quote chapter and verse when I'm not in my laboratory,
but I'm betting dollars to donuts that from configure.in
elif test $ac_cv_sizeof_long_double = 8; then
int64_literal='#define APR_INT64_C(val) (val##LD)'
uint64_literal='#define APR_UINT64_C(val) (val##ULD)'
At 03:00 PM 11/15/2003, Stas Bekman wrote:
In apache 1.3 one could check whether a r-finfo is already opened by checking
whether r-finfo.filehand is non-NULL. However with ap2/apr, r-finfo could be
unitilialized and containing random garbage.
However, we could null out r-finfo.valid and rest
17 matches
Mail list logo
