Home/ Questions/Q 8758427
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-13T14:32:43+00:00

I’ve migrated an Xcode iOS project from Xcode 3.2.6 to 4.2. Now I’m getting

  • 0

I’ve migrated an Xcode iOS project from Xcode 3.2.6 to 4.2. Now I’m getting warnings when I try to initialize a wchar_t with a literal with a non-ASCII character:

wchar_t c1;
if(c1 <= L'я') //That's Cyrillic "ya"

The messages are:

MyFile.cpp:148:28: warning: character unicode escape sequence too long for its type [2]
MyFile.cpp:148:28: warning: extraneous characters in wide character constant ignored [2]

And the literal does not work as expected – the comparison misfires.

I’m compiling with -fshort-wchar, the source file is in UTF-8. The Xcode editor displays the file fine. It compiled and worked on GCC (several flavors, including Xcode 3), worked on MSVC. Is there a way to make LLVM compiler recognize those literals? If not, can I go back to GCC in Xcode 4?

EDIT: Xcode 4.2 on Snow Leopard – long story why.

EDIT2: confirmed on a brand new project. File extension does not matter – same behavior in .m files. -fshort-wchar does not affect it either. Looks like I’ve gotta go back to GCC until I can upgrade to a version of Xcode where this is fixed.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    If in fact the source is UTF-8 then this isn’t correct behavior. However I can’t reproduce the behavior in the most recent version of Xcode

    MyFile.cpp:148:28: warning: character unicode escape sequence too long for its type [2]

    This error should be refering to a ‘Universal Character Name’ (UCN), which looks like “\U001012AB” or “\u0403”. It indicates that the value represented by the escape sequence is larger than the enclosing literal type is capable of holding. For example if the codepoint value requires more than 16 bits then a 16 bit wchar_t will not be able to hold the value.

    MyFile.cpp:148:28: warning: extraneous characters in wide character constant ignored [2]

    This indicates that the compiler thinks there’s more than one codepoint represented inside a wide character literal. E.g. L'ab'. The behavior is implementation defined and both clang and gcc simply use the last codepoint value.

    The code you show shouldn’t trigger either of these, at least in clang. The first because that applies only to UCNs, let alone the fact that ‘я’ fits easily within a single 16-bit wchar_t; and the second because he source code encoding is always taken to be UTF-8 and it will see the UTF-8 multibyte representation of ‘я’ as a single codepoint.

    You might recheck and ensure that the source actually is UTF-8. Then you should check that you’re using an up-to-date version of Xcode. You can also try switching the compiler in your project settings > Compile for C/C++/Objective-C

    • 0