Re: (not) breaking the ABI

[Mike Hearn <mike at navi dot cx>]

On Wed, 25 May 2005 14:28:43 +0100, chris jefferson wrote:
> As far as I've been able to find out, things we go into so_6 cannot:

e) Break semantic compatibility

In other words, apart from the type system there are things you can do
which will break software and are not backwards compatible, but won't
cause link failure. For instance:

- Changing memory allocation semantics of a function, eg dynamic -> static
  (as apps will then try and free something not on the heap)

- Changing a function that previously worked in a temporary buffer on the
  heap to scribble directly into a provided user buffer (because if the 
  operation fails half way through, the app now has an unexpectedly
  inconsistent buffer)

- Change the error code or exception thrown for a specific situation

- Change callback ordering (not sure if anything in libstdc++ actually
  generates callbacks ....)

- Reject input previously accepted as valid. That can include parameter
  validation! If you want to make a function more robust against errors
  it's possible that some program will rely on the code silently ignoring
  failure cases, so provide a special "robust" mode.

- Make something that was previously thread safe non-thread safe
  A variant on this is, "make it non-thread safe unless you set this magic
  variable". Well that isn't good enough obviously as old software will
  still break, magic variable or no. If you want to make that sort
  of  breaking change you need to make the magic variable opt *in* to the
  new behaviour not opt out.

OK so all this is pretty obvious but you'd be surprised at what gets
through ... I've seen *all* these things be done and break apps before.

There is more on library versioning and compatibility here:

  http://bylands.dur.ac.uk/~mh/writing-shared-libraries.html

It's targetted primarily at C libraries but the concepts are the same.

thanks -mike