Re: New ABI NSConstantString

[David Chisnall]

On 1 Apr 2018, at 11:36, Fred Kiefer <address@hidden> wrote:
> 
> Wouldn’t the most useful structure be the one we already use for GSString?
> 
> @interface GSString : NSString
> {
> @public
>  GSCharPtr _contents;
>  unsigned int _count;
>  struct {
>    unsigned int       wide: 1;        // 16-bit characters in string?
>    unsigned int       owned: 1;       // Set if the instance owns the
>                                       // _contents buffer
>    unsigned int       unused: 2;
>    unsigned int       hash: 28;
>  } _flags;
> }
> @end
> 
> Of course constant strings won’t require  the hidden reference count that 
> come with all ObjC objects. But apart from that it seems to be a more useful 
> structure. Storing the length with the string should speed up some common 
> operations and 28 bit of hash should still be enough. There are even two 
> unused bits in the flags that could encode the specific hash function.

It would probably help catch more bugs if we made use of NSString’s 
class-cluster nature more in -base.  I have just fixed a bug in GSString where 
we were checking one object matched a particular class before dereferencing the 
_flags ivar of the other.  I caught this because the other was a GSTinyString, 
which is almost never a valid pointer.

Prior to this, we were checking whatever data happened to be in the wide byte 
and, if the other string happened to have the _contents array in the same place 
we were doing something that probably wouldn’t crash but may or may not give 
the correct answer.

I don’t know if we have other bugs of this nature hidden by the fact that 99% 
of the time we’re using strings with the same structure.

David