On 1 Apr 2018, at 11:36, Fred Kiefer <fredkie...@gmx.de> 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 _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev