Re: ABI Compatibility (was Re: Installation woes for the average user...)

[Richard Frith-Macdonald]

On 5 Mar 2009, at 20:27, David Chisnall wrote:

> On 5 Mar 2009, at 16:10, Gregory Casamento wrote:
>
> > The last collective release was only two months ago.
> >
> > As far as the ABI is concerned that is certainly an issue.   The  
> > last time we discussed it we came up with two solutions:
> > 	• Pad the ivar-structures in the classes out to give space to grow  
> > so that it pushes off any ABI compatibility issues as long as  
> > possible.   This is why in some APIs, including Cocoa, you see  
> > things like "reserved..." or "private..." variables.  These are  
> > there to give room to grow.  The disadvantage is that the classes  
> > would then take up more memory as a result.
> > 	• Move the ivar-structures out of the classes and replace them  
> > with a void pointer to the actual structure.   This has the  
> > advantage that we will never be able to break ABI compatibilty  
> > since the sizes of the structs in the classes will not change...  
> > but it also has the disadvantage of adding a layer of complexity to  
> > getting and setting variables as well as potentially causing  
> > unpredictable issues due to unforseen incompatibilities such as  
> > cases where the wrong data is written into a data structure causing  
> > some sort of corruption when using the wrong version of a library.
>
> Or, option 3, use non-fragile ivars.  I plan on adding support for  
> this to the GNU runtime and the clang implementation over the next  
> few weeks.  It can be done without breaking the existing GNU runtime  
> ABI an, although it won't work retroactively, will let us change the  
> ivar layout of classes without subclasses requiring recompilation.   
> (Oh, please, please, don't do option 2 - it would break a lot of the  
> introspection that we use heavily in Étoilé).

That's interesting.  What sort of introspection do you do which needs  
to know about the layout of private ivars?  Shouldn't the KVC/KVO  
facilities be enough?

> Of course, this only applies to classes.  When people decide to  
> remove global variables that are referenced by static functions  
> declared in headers, this will still break the ABI, and really  
> shouldn't have been committed without a period of at least a year  
> while the relevant symbol was marked as deprecated.

You are referring to the NSZone thing?  Of course that hasn't been  
done.  We need people checking/using svn trunck to make sure we deal  
with any temporary breakage (or any completely accidental breakage)  
before a release.

I feel we probably need to break things in trunk during the  
development cycle to get a reaction and some suggestions from other  
people.  For instance I asked for ideas about the change to using  
NSUInteger,NSInteger, and CGFloat, and I adopted your idea of a  
#define to retain the old style behacvior, but since then I've seen no  
feedback about making this change work with gui/back and other apps.   
What I probably need to do is switch that code to use the new Apple  
behavior by default, deliberately breaking 64bit systems so that  
people will do something about it, or will at least sned specific bug  
reports for me to deal with.