On 11/01/16 18:29, Viktor Dukhovni wrote: > >> On Jan 11, 2016, at 5:23 AM, Tomas Mraz <tm...@redhat.com> wrote: >> >> On Po, 2016-01-11 at 01:09 +0000, Peter Waltenberg wrote: >>> The point of using accessor FUNCTIONS is that the code doesn't break >>> if the structure size or offsets of fields in the underlying >>> structures change across binaries. >>> >>> Where that mainly has an impact is updating the crypto/ssl libs >>> underneath existing binaries is more likely to just work. >>> >>> #defines in the headers do not help at all here. >>> >> >> The point is in achieving reverse API compatibility between 1.1 and >> 1.0.2. No binary compatibility is expected between those branches. >> >> I think that having the API compatibility would be really useful thing >> easing porting application code to 1.1 branch. > > Yes, although in practice may users of 1.0.x will have previous releases > that don't have the accessors, so the issue is difficult to address > retroactively in OpenSSL. In Postfix, I add the macros myself: > > #if OPENSSL_VERSION_NUMBER < 0x10100000L > #define X509_up_ref(x) (CRYPTO_add(&x->references, 1, CRYPTO_LOCK_X509)) > #endif > > Which means that interestingly enough adding these to 1.0.x would break > my code and similar code elsewhere. > > So on the whole forward-compatibility macros don't fully address the > problem, and may do as much harm as good. > > I think that applications porting to 1.1.0 can and should implement > their own macros against a stable 1.0.x API that we don't change > at the last minute. Providing your own forward-compatible glue > is easy enough... >
Perhaps someone from the community could contribute a (separately maintained) compatibility layer to provide the relevant macros? Matt _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev