apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: svn commit: r890580 - in /apr/apr-util/branches/1.4.x: crypto/apr_crypto.c crypto/apr_crypto_nss.c crypto/apr_crypto_openssl.c include/apr_crypto.h include/private/apr_crypto_internal.h test/testcrypto.c
Date Tue, 15 Dec 2009 10:27:41 GMT
William A. Rowe Jr. wrote:

> And I think it's overkill.  If the 'incomplete' apr_crypto_t is defined to always
> complete to a first member referencing the apr_crypto_driver_t, we just don't need
> this uglyness.  A similar example was using pools as the first member of arbitrary
> apr types to always ensure the pool-of could be extracted from an arbitrary type.
> The implementation of apr_crypto_error can simply map apr_crypto_t to the predictable
> initial elements, e.g. pool and driver.
> Make sense?

It does, but if we do this, apr_dbd.h, which contains this same pattern
(and on which apr_crypto was based) needs to be changed at the same time
for the same reason.

(Obviously ABI-wise this is a 2.0 thing).


View raw message