[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.
David
-- Send from my Jacquard Loom
Hi,
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 ((p.name != 0) && (strcmp(name, p.name) != 0)) { return NO; }
-----
and the same applies to the use of the 'V' attribute in
propertyFromAttrs() above that.
=====
EXPLANATION:
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
objc_properties.m
Description: Text document