I'm just evaluating replacing our old CFLite code base, which is based on 368.28 with the latest OpenCFLite, but I've stumbled across problems with CFStringCompareWithOptions:
when I pass kCFCompareNonLiteral or kCFCompareLocalized, CFStringCompareWithOptions does not work as expected for non-ASCII strings. The old code based on Apple's CFLite did do the correct comparison (at least to the extend we tested), but the new OpenCFLite code based on 476.17 does not.
For the kCFCompareLocalized option, it boils down to the macro definition
#define _CFCompareStringsWithLocale(A, B, C, D, E, F) (0)
at line 2391 of CFString.c, which apparently is a placeholder inserted by Apple for some proprietary implementation of the localized string comparison.
For the kCFCompareNonLiteral (without kCFCompareLocalized), the code no longer decomposes the strings as it did in the 368.28 based code. Not sure why this was removed or whether it would be in Apple's proprietary implementation of _CFCompareStringsWithLocale?
Has anybody worked on this problem or does anybody have a suggestion where & how to start fixing this?
Thanks,
-jens
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the case of kCFCompareNonLiteral (without kCFCompareLocalized), it turned out to be false alarm: I had the characterset bitmaps copied to the wrong location, thus decomposing did not work. Once I copied the files to the expected location, non-literal comparison works.
I still have the question about comparing with kCFCompareLocalized, though:
Has anybody used this option so far?
My current approach is a little modification to CFStringCompareWithOptionsAndLocale in CFString.c that does not fetch the current locale, thus _CFCompareStringsWithLocale is not called.
Obviously, this makes the kCFCompareLocalized option a noop, but it's still better than obviously wrong results, even for ASCII strings.
I'd still like to hear when somebody has a clean solution for this.
Thanks,
-jens
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'm just evaluating replacing our old CFLite code base, which is based on 368.28 with the latest OpenCFLite, but I've stumbled across problems with CFStringCompareWithOptions:
when I pass kCFCompareNonLiteral or kCFCompareLocalized, CFStringCompareWithOptions does not work as expected for non-ASCII strings. The old code based on Apple's CFLite did do the correct comparison (at least to the extend we tested), but the new OpenCFLite code based on 476.17 does not.
For the kCFCompareLocalized option, it boils down to the macro definition
#define _CFCompareStringsWithLocale(A, B, C, D, E, F) (0)
at line 2391 of CFString.c, which apparently is a placeholder inserted by Apple for some proprietary implementation of the localized string comparison.
For the kCFCompareNonLiteral (without kCFCompareLocalized), the code no longer decomposes the strings as it did in the 368.28 based code. Not sure why this was removed or whether it would be in Apple's proprietary implementation of _CFCompareStringsWithLocale?
Has anybody worked on this problem or does anybody have a suggestion where & how to start fixing this?
Thanks,
-jens
In the case of kCFCompareNonLiteral (without kCFCompareLocalized), it turned out to be false alarm: I had the characterset bitmaps copied to the wrong location, thus decomposing did not work. Once I copied the files to the expected location, non-literal comparison works.
I still have the question about comparing with kCFCompareLocalized, though:
Has anybody used this option so far?
My current approach is a little modification to CFStringCompareWithOptionsAndLocale in CFString.c that does not fetch the current locale, thus _CFCompareStringsWithLocale is not called.
Obviously, this makes the kCFCompareLocalized option a noop, but it's still better than obviously wrong results, even for ASCII strings.
I'd still like to hear when somebody has a clean solution for this.
Thanks,
-jens