[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Strange crash in __objc_resolve_class_links

From: Ivan Vučica
Subject: Re: Strange crash in __objc_resolve_class_links
Date: Wed, 16 Feb 2011 11:53:56 +0100

On 16. vel. 2011., at 11:26, Richard Frith-Macdonald <address@hidden > wrote:

On 15 Feb 2011, at 21:34, Ivan Vučica wrote:

ZCPBXProjectReader *r = [[ZCPBXProjectReader alloc] initWithFile:@"does_not_exist.pbxproj"];
       (void) r.plist;
       assert(r.errorMessage != nil);
       [r release];

As far as I can see nobody has replied to this ...

Strange, both David and Jason joined the discussion :-)

perhaps because there's really not much to go on as we don't know where things might be going wrong (crashes in the runtime library are usually caused by memory corruption for instance).

So, we could be looking at a problem caused earlier in the code, or something hidden in one of the methods called within this check.

That's why I posted the instructions on getting the code, in case someone wants to investigate :-)

David already suggested grabbing real libobjc2 from GNUstep repo, so we will try that first.

Incidentally, when most of the GNustep maintainers met at FOSDEM this year, we decided to ban the use of the '.' operator for property access within GNUstep ... it's pretty universally thought to encourage bad code by obscuring what's going on, and your example above is a case in point ... the '(void)r.plist;' would conventionally be thought of as a reference to an instance variable, and since the value is not used, many people would expect the compiler to simply optimise away that line of code completely. You ought to use '(void) [r plist];' instead. Similarly, 'r.errorMessage' obscures the fact that messaging is going on ... it ought to be [r errorMessage].

I respectfuly, but strongly disagree.

One of the reasons why I love ObjC is readability and clarity of intention. Key thing here is the intention. Intention of "grabbing a property of an object" as opposed to "getting a result of an operation" is clearly stated with the dot syntax. It does not matter how the property is generated. It is the method developer's duty to make sure nothing weird is going on. If he wants to calculate something and cache the result of a calculation in an NSDictionary, that is his choice. Most people will use synthesize.

Not using dot syntax because it "hides the fact that you are calling a method" is pretty funny to me. It is easy to see if something is an object or a pointer; dot syntax would clearly be invalid there unless one uses it to access a property. To access ivar, those confused developers should anyway know the -> operator is used. (And that is something I would ban nowadays, except in highly performance sensitive code. Why should other classes be aware of the internals of this particular class, or touch its ivars?)

Use in setters also shortens the code and sometimes significantly clarifies intent -- especially with the += operator.

Optimization is not an issue either; it can be done after profiling. Performance sensitive code can be rewritten.

Finally, because the '.' syntax is deprecated (and someone at FOSDEM said it behaves differently in different versions of clang), it is certainly not well tested ... you might find that removing it makes the crash in your code go away as well as improving the code clarity.

I feel dot syntax adds to code clarity and that bugs in compiler should be resolved in the compiler, not by making changes to the code. Dumping dot syntax for this project may be possible, but is that a long term solution?

Avoiding dot syntax within GNUstep may be fine. But I don't think philosophical issues should be used to block other developers from using it, as well as other ObjC2.0 features. It is especially tricky if it blocks easier porting of existing code.

If things work with latest clang, latest gcc and latest GNUstep SVN, and the way to set up ObjC2.0 environment is documented (which I think it should be, if it isn't) -- then long term solution is achieved and there is no problem. :-)

Finally, for future projects and other decisions, I need to know:

Is the stance of GNUstep project that ObjC2.0 will, long term, be unsupported in apps?


Ivan Vučica
via phone

reply via email to

[Prev in Thread] Current Thread [Next in Thread]