Re: Heads Up: ABI Change

[David Chisnall]

Hi Stefan,

On 11 Feb 2011, at 19:02, Stefan Bidi wrote:

> On Fri, Feb 11, 2011 at 9:15 AM, Richard Frith-Macdonald <address@hidden> 
> wrote:
>> No ... this sort of stuff rarely actually breaks anything (how often does 
>> anyone want to subclass these things) but we have a 'contract' with our uses 
>> not to break ABI compatibility for stable releases (except very rarely on a 
>> major release).  I would really like to be able to make a new minor stable 
>> release (so distributions can adopt it quickly without worrying about 
>> backward compatibility) by copying from svn trunk.  So really we want to 
>> make sure that there are no changes in the size of the ivars of existing 
>> classes.  This means that either we need to modify things so we are not 
>> using any new ivars in NSDateFormatter and NSNumberFormatter, or our next 
>> stable release really can't contain the latest implementation for these two 
>> classes. The 'padding' instance variable in each class definition is there 
>> precisely so that we can set gs_unused to be a pointer to extra data if we 
>> need to add instance variables without breaking the ABI.
>>  
> The changes to the formatters were quite invasive, including breaking the 
> default behavior as they now default to 10.4+ behavior.  I really couldn't 
> use the padding pointer because I added a lot of new ivars.  The only way I 
> could have done anything with it is if I made it a pointer to a structure.  
> Is this what I should have done here?
> 
> The good news is that I didn't modify anything else but add the new behavior, 
> so a new stable release can be done by simply omitting all the changes I did.

I've not looked at the code in detail, but I thought you were creating a 
private subclass for the old and new behaviours - would it not be possible to 
simply return a private subclass instance from the constructors and not change 
the ivar layout of the superclass?

David

-- Sent from my PDP-11