apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: [PATCH] Optimized MD5 implementation from OpenSSL
Date Wed, 03 Jan 2007 17:18:30 GMT
On Wed, Jan 03, 2007 at 08:29:54AM -0800, Justin Erenkrantz wrote:
> On 1/3/07, Joe Orton <jorton@redhat.com> wrote:
> >This would need to have some severe future-proofing to be safe against
> >any change to MD5_CTX in future versions of OpenSSL, e.g. only using it
> >for the specific sizeof() that structure as currently defined.  (that
> >would cover the cases where MD5_LONG is currently not 32-bit too)
> Well, I think the 'right' solution may be to deploy a new MD5 API that
> takes a pool and we can dynamically allocate the MD5_CTX rather than
> asking the client to allocate it off the stack.

Making apr_md5_ctx_t opaque would require bumping the APR-util major 
version either way; if there's enough desire to break API that might as 
well be the way to go?

Alternatively, a slightly less hacky way (and perhaps well-defined C 
code :) might be to "thunk" between the two structures in each function, 
building the MD5_CTX on the stack, with the MD5_CTX ->num in the ->xlate 
field.  Though that might dilute the performance gain somewhat and adds 
little over your original patch; not sure it's any better really.

On balance, +0 to your patch.  The reason I ask about the error values 
was this comment regarding dropping apr_status_t from the interface in 
apr's STATUS:

      david: This was rejected for 1.0 following Ben L's comment that
             should we ever start using any other form of md5 (e.g.
             openssl) then errors would become a distinct possibility.

but if that really can't happen, no big deal...



View raw message