"Qt for macOS - Specific Issues": sample code is wrong

In the "Qt for macOS - Specific Issues" document, section "macOS Native API Access", subsection "Accessing the Bundle Path", the sample code is wrong. Because of this, a warning has been added about the code failing on a system localized to Japanese, just one of several potential failure cases. But it's not a Mac bug, it's an incorrect use of Mac system APIs in the sample given.

The problem originates with the misleading name (and obscure Apple documentation) of the function CFStringGetSystemEncoding(). "System" here refers to the context of legacy (Mac OS 9) resource files, as stated (however incomprehensibly) in the Apple documentation. This call has no conceivable correct use in the context of Qt. The encoding it returns is always wrong for filesystem use on current macOS (Mac OS X), and seems okay only for filenames that are limited to 7-bit ASCII.

Instead of CFStringGetCStringPtr() with CFStringGetSystemEncoding(), the correct API to use when extracting a path name for use with POSIX is CFStringGetFileSystemRepresentation()
Alas, you have to allocate a char* buffer to use this function, a length upper bound for which is given by CFStringGetMaximumSizeOfFileSystemRepresentation(). But this is really the only correct way to get a POSIX path from a CFString.

As a quick-and-dirty workaround, you might use CFStringGetCStringPtr() with the constant UTF8 for the encoding. However, this will not always give a string that can be used to access the file, because of Unicode canonical (de)composition issues. Also, this function is not guaranteed to return non-NULL (hence the warning in the Qt document), as it is designed to return a valid pointer only if the internal representation of the CFString is compatible with the encoding requested. Really not a good choice for sample code.