apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
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:48:29 GMT
Graham Leggett wrote:
> 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).

As I mentioned, the actual contents of the structure are flexible IMHO.
As a user, folks aren't expected to know the difference, but as a developer,
something clearly labeled -alpha should be expected to be changing still.

So if a *developer* coded to any of these API's, well, all bets are off.

But we can leave the apr_crypto_driver_t at the same position as it was
originally in the structure, no?

Mime
View raw message