Sorry to be replying to my own e-mail, but I figured it out...
GSEQ_STRCOMP() calls -rangeOfComposedCharactersAtIndex: and CFString was
just returning {0, 0} for that call. I still can't really follow what this
function does, but that seems like a weird method to call since NSString
just return {0, 0}, as well, and it would break any NSString subclass that
doesn't specifically override this method.
After fixing this function in CFString the tests are now all passing.
Stef
On Sun, Jul 10, 2011 at 10:42 AM, Stefan Bidi <[email protected]> wrote:
> I just added the missing bits to the toll-free bridging code in corebase
> but I'm running into some problems when comparing NSCFStrings to other
> types, like NSConstantString. The PASS_CFEQ() macro in CFTesting.h calls
> CFEqual, which in turn calls -isEqual: if either object is an objective-c
> object. The CFSTR() macro just turns into @"" when called from within a .m
> file, and since all test files are .m files all the test strings are an
> instance of NSConstantString.
>
> That should be enough background... The problem I'm running into is that
> [NSConstantString -isEqual:] is returning NO on instances of NSCFString. I
> tried following the GSEQ_STRCOMP() code in GSeq.h but I can't make heads or
> tails of it. I setup a breakpoint in CFStringGetCharacters() and the range
> passed onto it is {0, 0}. So it doesn't return anything useful.
>
> Can someone more familiar with the code there shed some light on what might
> be going on? I've already had to fix a few bugs in CFString that this
> exposed, so I've got a mistake somewhere else, but I can't follow the code
> well enough to figure out where.
>
> Thanks
> Stef
>
_______________________________________________
Gnustep-dev mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnustep-dev