[Cryptography] Apple and OpenSSL

[ianG]

On 21/04/2014 07:45 am, Peter Gutmann wrote:
> Jerry Leichter <leichter at lrw.com> writes:
> 
>> 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.)


This makes for a pretty good reason to use objects not structs.

However, if you need to persist your objects (and who doesn't) you're
back to the same problem.  In general, I find that each object always
needs a version number (and also for super classes) and then the object
can unpersist itself, being kinder to older generations.

However, if you're upgrading asymmetrically, such as e.g., clients and
servers, where you control the servers and can upgrade them now but
clents cannot handle new versions until later upgrade, then the trick
with spare fields starts to pay off.


> I use a slightly different approach: Don't assume a C API/ABI.  If your API
> can deal with C, Java, Perl, Tcl, Delphi, and Visual Basic, all via the single
> API,


What rules/guidelines do you use to achieve that?


iang



> then there's a pretty good chance that you're not going to break things
> via some change in a C-only API artefact.
> 
> Peter.