On Wed, Jan 03, 2007 at 08:29:54AM -0800, Justin Erenkrantz wrote:
> On 1/3/07, Joe Orton <[EMAIL PROTECTED]> 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...
Regards,
joe
