[Top][All Lists]

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

Re: Dynamically added properties problem

From: Luboš Doležel
Subject: Re: Dynamically added properties problem
Date: Mon, 15 Oct 2012 21:27:42 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1

On 10/09/2012 02:36 PM, David Chisnall wrote:
On 9 Oct 2012, at 10:45, Luboš Doležel wrote:

When looking at the code of both functions, class_addProperty()
sets the count in objc_property_list to 0, even though it memcpy()s
the property into that property list. This results in
class_copyPropertyList() not taking that property into account.

That is, indeed, a bug.  Fixed in svn r35658, thank you.


-- Send from my Jacquard Loom


I think I've found another problem in the same function. This one is much more serious, as it involves even properties declared at compile time.

So, this is wrong:

// If there is a name mismatch, the attributes are invalid.
if (( != 0) && (strcmp(name, != 0)) { return NO; }

and the same applies to the use of the 'V' attribute in propertyFromAttrs() above that.


The property name is *not* what is contained within the property attributes. Property attributes contain the name of the ivar that holds the data of that property. In 99% of cases, these two are identical. But they may not be.

See the attached sample app. On OS X, this generates a property named "propName" with attribute string "Ti,VvarName".

osx:~ lubos$ ./objc_properties
1 properties
propName Ti,VvarName

On Linux with libobjc2, this generates something quite different:

$ ./objc_properties
1 properties
propName Ti,VpropName

So the solution I would think of is:

1) Remove the check from class_addProperty(). protocol_addProperty() seems OK.

2) Add another field into struct objc_property called ivarName or something and store the 'V' attribute in there via propertyFromAttrs().

**We can't do it like this, it breaks the ABI!**

3) Fix property_copyAttributeList() to use the new field for the 'V' attribute when generating the attribute string.

4) property_getAttributes() seems to be totally wrong:

- it assumes that ivar name == property name, that's clear;
- it doesn't free the original name buffer;
- by changing the name string into an encoded attribute list, it breaks class_getProperty() which doesn't take that into account.

5) Maybe something else, I not yet that familiar with the codebase.

What worries me most is the ABI problem. The ivar names don't seem to be currently saved into properties by Linux compilers at all!

On OS X, property attributes are stored as a single string. This is also much more extensible. My real suggestion would be to adapt this idea, hack it into struct objc_property somehow and push a fix into Clang.

Best Regards,
Luboš Doležel

Attachment: objc_properties.m
Description: Text document

reply via email to

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