Re: Dynamically added properties problem

[David Chisnall]

Hi Luboš,

The property metadata stored by clang was designed to be enough to support the 
introspection APIs that existed when it was designed.  Unfortunately, Apple 
then added property_getAttributes(), which just dumps the Apple runtime's 
internal representation of the format.  This isn't really extensible, because 
any parser written for it now may break in the future - we should have learned 
that lesson for type encodings, where it's incredibly hard to add new types 
sensibly (see the block type encoding fiasco) without breaking all existing 
code that uses them.

I've now modified clang to generate this string if -fobjc-runtime=gnustep-1.6 
or greater.  This relies on logic that in the runtime was not present in 1.5, 
so is not enabled for older runtimes.

David

On 15 Oct 2012, at 20:27, Luboš Doležel wrote:

> 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>_______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev


-- Sent from my Cray X1