NSXMLNode ivar type

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

NSXMLNode ivar type

David Chisnall-7
Hello the list,

I am working on the new ObjC ABI and one of the changes I have made is to include the type encoding in the ivar offset variable.  This protects against type confusion by causing linker failures when an instance variable is referenced with the wrong type (which can happen if it’s in a library that changes and someone forgets to bump the SONAME).

Unfortunately, I have found that -base doesn’t build because it uses some complex preprocessor logic to change the type of NSXMLNode’s node ivar depending on which subclass you are using.  This is quite dangerous because, although the types have a common prefix, the version used in the root is not a prefix of the others and so it’s possible for type confusion if someone modifies NSXMLNode without realising how the subclasses use this.

Does anyone object if I commit a patch that turns this into a union?

David


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: NSXMLNode ivar type

Ivan Vučica-2
On Tue 20 Mar 2018 at 14:51 David Chisnall <[hidden email]> wrote:
Hello the list,

I am working on the new ObjC ABI and one of the changes I have made is to include the type encoding in the ivar offset variable.  This protects against type confusion by causing linker failures when an instance variable is referenced with the wrong type (which can happen if it’s in a library that changes and someone forgets to bump the SONAME).

Unfortunately, I have found that -base doesn’t build because it uses some complex preprocessor logic to change the type of NSXMLNode’s node ivar depending on which subclass you are using.  This is quite dangerous because, although the types have a common prefix, the version used in the root is not a prefix of the others and so it’s possible for type confusion if someone modifies NSXMLNode without realising how the subclasses use this.

Does anyone object if I commit a patch that turns this into a union?

David

Please bump the SONAME while at it :)

--
Sent from Gmail Mobile

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: NSXMLNode ivar type

David Chisnall-7
On 20 Mar 2018, at 15:36, Ivan Vučica <[hidden email]> wrote:

>
> On Tue 20 Mar 2018 at 14:51 David Chisnall <[hidden email]> wrote:
>> Hello the list,
>>
>> I am working on the new ObjC ABI and one of the changes I have made is to include the type encoding in the ivar offset variable.  This protects against type confusion by causing linker failures when an instance variable is referenced with the wrong type (which can happen if it’s in a library that changes and someone forgets to bump the SONAME).
>>
>> Unfortunately, I have found that -base doesn’t build because it uses some complex preprocessor logic to change the type of NSXMLNode’s node ivar depending on which subclass you are using.  This is quite dangerous because, although the types have a common prefix, the version used in the root is not a prefix of the others and so it’s possible for type confusion if someone modifies NSXMLNode without realising how the subclasses use this.
>>
>> Does anyone object if I commit a patch that turns this into a union?
>>
>> David
>>
> Please bump the SONAME while at it :)

Why?  It’s an private and hidden ivar.  In the fragile ABI, it’s in the secret ‘internal’ structure and not ABI-visible, in the non-fragile ABI it’s in a class extension and so not externally visible.

David



_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: NSXMLNode ivar type

Ivan Vučica-2
Got it.

I thought it was more exposed.
On Tue 20 Mar 2018 at 16:14 David Chisnall <[hidden email]> wrote:
On 20 Mar 2018, at 15:36, Ivan Vučica <[hidden email]> wrote:
>
> On Tue 20 Mar 2018 at 14:51 David Chisnall <[hidden email]> wrote:
>> Hello the list,
>>
>> I am working on the new ObjC ABI and one of the changes I have made is to include the type encoding in the ivar offset variable.  This protects against type confusion by causing linker failures when an instance variable is referenced with the wrong type (which can happen if it’s in a library that changes and someone forgets to bump the SONAME).
>>
>> Unfortunately, I have found that -base doesn’t build because it uses some complex preprocessor logic to change the type of NSXMLNode’s node ivar depending on which subclass you are using.  This is quite dangerous because, although the types have a common prefix, the version used in the root is not a prefix of the others and so it’s possible for type confusion if someone modifies NSXMLNode without realising how the subclasses use this.
>>
>> Does anyone object if I commit a patch that turns this into a union?
>>
>> David
>>
> Please bump the SONAME while at it :)

Why?  It’s an private and hidden ivar.  In the fragile ABI, it’s in the secret ‘internal’ structure and not ABI-visible, in the non-fragile ABI it’s in a class extension and so not externally visible.

David



_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev