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). Regards, Graham --
