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?
