[Cryptography] Apple and OpenSSL

[Jerry Leichter]

On Apr 20, 2014, at 8:01 PM, Theodore Ts'o <tytso at mit.edu> wrote:
> If you design your interfaces to maximize ABI stability (and you don't
> use C++, because every single time you add even a private variable to
> the base class, it breaks ABI compatibility for all of the
> subclasses), it is possible to make this kind of ABI stability for far
> longer than "we'll break the world every year or two".
Of course, the same thing happens in C if you duplicate the underlying cause:

struct A {
...
}

struct B {
   struct A a;
   ...
}

If you do anything that changes struct A's length, everything referring to B is likely to break.

I implemented a workaround for this many years ago:  Add a couple of spare fields of a couple of basic types.  Should you need to do a patch while retaining ABI compatibility, just start using one of the spares.  (In C++, you also want a couple of spare virtual function entry points.)

(The goal in my case wasn't ABI compatibility as such.  The system involved was structured as a tiny main program, with all the functionality implemented in a large number of dynamically loaded libraries.  Servers for different purposes were configured by telling the main program what to load.  Changes to low-level libraries required rebuilding *everything*, which made for large patch files that *changed* everything, which made for unhappy customers.  The spare fields and entry points trick let us push that off to the next major release, when people expected everything to change anyway.  Using the macro pre-processor made this easy to manage:  If you needed a new int field name xCounter, you could #define xCounter int_field_1 for the current release, then add the new xCounter field and get rid of the #define for the next release.)

                                                        -- Jerry