Home/ Questions/Q 7962809
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-04T05:26:59+00:00

Please consider the following code: NSString *string = @ä; const char *str1 = [string

  • 0

Please consider the following code:

NSString *string = @"ä";
const char *str1 = [string cStringUsingEncoding:NSUTF8StringEncoding];
const char *str2 = "ä";
NSLog(@"C string comparison: %d",strcmp(str1,str2));
NSLog(@"str1: \"%s\"", str1);
NSLog(@"str2: \"%s\"", str2);

If run from a brand-new Foundation project, this program outputs:

C string comparison: 0
str1: "ä"
str2: "ä"

This is indeed what I expect to happen, because the strings are supposed to be the same.

However, if I run this exact same code somewhere deep within another codebase, I get this output:

C string comparison: 31
str1: "ä"
str2: "ä"

What could possibly explain this difference? I’m pretty sure both files are in the UTF-8 encoding. That — different file encodings — is the only possible explanation for this behavior, right?

Any ideas what could have gone wrong in the second case? How can I fix it?

(I should maybe mention that in the second case, the code is being run in an .mm file, i.e. under Objective-C++. Can that be an explanation for this?)

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    How a source file is encoded on disk is one thing. How the compiler believes it is encoded is another. By default, GCC assumes UTF-8 but it can be told it’s in another encoding from the locale or the -finput-charset=<charset> option. I expect that Clang supports the same thing.

    Xcode has its own notion of the encoding of a source file. I don’t know if it adjusts the compile command to pass that in using the above option, but I wouldn’t be surprised.

    GCC also has a notion of the execution character set. This is how it writes strings into the binary. See the -fexec-charset=<charset> option.

    So, the compiler interprets the bytes of the file according to the input character set and writes them out to the binary in the execution character set. If those two differ, then that involves a conversion. This is a per-translation unit affair, so it can happen differently for different source files.

    Another issue is that “ä” has two possible representations in Unicode. It can be LATIN SMALL LETTER A WITH DIAERESIS (U+00E4) or it can be LATIN SMALL LETTER A (U+0061) followed by COMBINING DIAERESIS (U+0308). In UTF-8, that would be 0xC3 0xA4 vs. 0x61 0xCC 0x88. Your two source files may express the same character differently, which means they really do contain different strings (at all levels: C string, NSString, whatever, although NSString will ignore that difference for -compare:... methods if NSLiteralSearch is not specified; the -isEqual... methods do a literal compare, though). This would, of course, be exacerbated if those two byte sequences were being converted among encodings in different ways.

    So, you need to track down the specific source files which contain the relevant strings. Check with a hex dump exactly which bytes they contain. Check the commands used to compile them (and possibly the environments if locale may play a role) to see what the compiler believes about the input and executable character sets.

    • 0