What is a non-fragile ABI?

Question

It may seem implied that everyone knows what a "Non Fragile ABI" is - considering the frequency and matter-of-fact-nature to which it is referred to - within Xcode. For example...

Subscript requires size of interface node which is not constant in non-fragile ABI

or

Select the Objective-C ABI version to use. Available versions are 1 (legacy "fragile" ABI), 2, (non-fragile ABI 1), and 3 (non-fragile ABI 2).

That said... What is a non-fragile ABI? (and why isn't it called something less-abstract / explained more clearly?)

Have you even tried to google it? non-fragile ABI isn't something Apple invented, and they aren't the only ones that are using it. If you look in the Internet, (almost) no single piece of documentation explains what "non-fragile ABI" is before using the term. — Daniel, Sep 20 '12 at 23:40
Don't blame Apple here. What you're looking at is a term of art in the field; a quick search turns up its use with C++ and D as well. For more, see [the Ur-Wiki](http://c2.com/cgi/wiki?FragileBinaryInterfaceProblem). — Jeremy W. Sherman, Sep 20 '12 at 23:41
"What really rubs me the wrong way is the slightly presumptuous tone which almost everything is written." Read that again. Apply to OP. Appreciate pot-kettle-black. — Jeremy W. Sherman, Sep 20 '12 at 23:43
And because it has to be said: Radar or it didn't happen. The documentation team does update documentation in response to radar bugs filed. — Jeremy W. Sherman, Sep 20 '12 at 23:45
Your rant and tone are not appropriate for StackOverflow, so I've edited your question to make it more objective; see? (har har). — Dave DeLong, Sep 21 '12 at 04:23
@DaveDeLong i'd bother disagreeing.. but what choice do I have? it's funny that reputation is called flair, around here.. as it certainly is never appreciated. — Alex Gray, Sep 21 '12 at 04:39
@JeremyW.Sherman: Usages in C++ and D don't really explain anything about Apple's use of it in the context of the Objective-C runtime. — Peter Hosey, Sep 21 '12 at 05:33
@PeterHosey It's the same problem as in C++ and D. A high-ranked D search result says, "In C++, whenever you add, change or remove a virtual method or a variable as a member of a class or struct, you’re probably breaking binary compatibility and must recompile everything depending on that" (["Non-fragile ABI in D?"](http://michelf.ca/blog/2009/non-fragile-abi-in-d/)) It links to [the WP article](https://en.wikipedia.org/wiki/Fragile_binary_interface_problem) in the next paragraph. The vtable problem didn't affect Obj-C, but the instance variable problem did, and that's what was solved. — Jeremy W. Sherman, Sep 21 '12 at 06:14
[Second Apple dev hit](https://duckduckgo.com/?q=!appledev+non-fragile+abi) for non-fragile ABI leads to [Obj-C Release Notes](https://developer.apple.com/library/mac/#releasenotes/Cocoa/RN-ObjectiveC/_index.html), which explains: "All instance variables in 64-bit Objective-C are non-fragile. That is, existing compiled code that uses a class's ivars will not break when the class or a superclass changes its own ivar layout. In particular, framework classes may add new ivars without breaking subclasses compiled against a previous version of the framework." — Jeremy W. Sherman, Sep 21 '12 at 06:17
Yes @Dani, I did try to google and this is what came up as the top result ;^) — Anton Tropashko, Oct 27 '21 at 09:58

bbum · Answer 1 · 2012-09-20T23:04:56.403

The non-fragile ABI refers to the ability to add instance variables to a class without requiring recompilation of all subclasses.

I.e. in v1 (there really aren't true versions of ObjC), if Apple were to add an instance variable to, say, NSView (on Cocoa, 32 bit), then every subclass of NSView (or subclass of subclass) would have to be recompiled or they would blow up. v2 and v3 fix this.

It is explained in detail in this weblog post.

The documentation you are referring to is in the llvm/clang man page. Pretty rare place to be for most developers most of the time; unless you are writing a Makefile that is driving the compiler directly, there isn't much reason to read that page (unless spelunking -- which is quite educational, of course).

It is written in the style of a Unix man page and, no surprise, is a bit... obtuse. For almost all tasks, it is best to stick to the higher level documentation. I.e. the Xcode build settings documentation is general quite a bit less obtuse.

score 0 · Answer 2 · answered Sep 21 '12 at 14:12

After some poking around, one of the best summaries / pieces of advice on the subject is the following…

The non-fragile ABI allows for things like changing the ivars of a superclass without breaking already compiled subclasses (among other things). It's only supported on 64-bit on the Mac though, because of backwards compatibility concerns which didn't allow them to support it on existing 32-bit architectures.

It goes on to say, basically.. that if Xcode, which often is configured to build for the "Active Architecture Only", aka 64-bit only.. one may run into issues when switching to a "Release" scheme, which is usually set to build for both (63bit/32bit) architectures, aka "Universal"..

You may you want to use ARC on the Mac, I'm pretty sure you'll have to drop 32-bit support to do so. You can change the targeted architectures in the build settings for your target in Xcode.

In my own experience, I believe that what the non-fragile ABI benefits us with is an abbreviated syntax, and patterns such as…

//  source.h  - readonly public properties.  
@interface SuperClassy : NSObject
@property (readonly) NSArray *cantTouchThis;
@end
// source.m  set readonly properties, internally.  
@implementation SuperClassy
// look, no @synthesize… just use _ivarName.
 -(void) touchIt:(NSArray*)a { _cantTouchThis = a; }    
@end
int main(int argc, const char * argv[]) {
    SuperClassy *it = [SuperClassy new];
    // you cannot set it.cantTouchThis = @[anArray].
    [it touchIt:@[@"cats"]];  
    // but you can via a method, etc.
    NSLog(@"%@", it.cantTouchThis);
}

NSLOG ➜ ( cats )

[As @bbum said](http://stackoverflow.com/a/12522123/115730), the non-frabile ABI has to do with allowing Apple to change their ivar layouts in between releases of the operating system. It has nothing to do with auto-synthesizing instance variables and abbreviating syntax (which is what I'm getting from your code sample); those are syntactic sugar put in to the compiler. — Dave DeLong, Sep 21 '12 at 14:59
If I remember correctly, some of the autosynthesis stuff is limited to the modern runtime, but only because there was no motivation to expend the engineering resources on the legacy runtime, not because there was any particular technical barrier. — bbum, Sep 22 '12 at 21:49
@DaveDeLong No, the example illustrates the ability to set properties, privately, á la a Class extension, [which is described nicely, here](http://www.friday.com/bbum/2009/09/11/class-extensions-explained/). — Alex Gray, Sep 22 '12 at 22:00
@alexgray there's no such thing as privately setting a property, because there is no such thing as a private method in objective-c; there are only methods to which you do not have the symbol. What you're doing in your example is just changing the instance variable that happens to back that property. — Dave DeLong, Sep 23 '12 at 02:59

What is a non-fragile ABI?

2 Answers2

Linked