Re: Strange crash in __objc_resolve_class_links

[Ivan Vučica]

On 16. vel. 2011., at 11:26, Richard Frith-Macdonald <richard@tiptree.demon.co.uk 
> wrote:

> On 15 Feb 2011, at 21:34, Ivan Vučica wrote:
>
> > CHECK(ZCPBXProjectReader_returns_error_message)
> > {
> >        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?

Regards,

Ivan Vučica
via phone