bug#42904: [PATCH] Non-Unicode frame title crashes Emacs on macOS

[Mattias Engdegård]

17 aug. 2020 kl. 21.56 skrev Alan Third <alan@idiocy.org>:

> Sorry if this is a stupid question, but would using UTF-16 be easier?
> This appears to work (although I'm sure it's not the right way to do this):

A good question! It has the advantage of requiring no new code, but is slightly 
inferior in that raw bytes are not replaced with U+FFFD but with spaces; we 
should probably set :default-char to #xfffd for the utf-16 coding systems.

Unpaired surrogates are handled splendidly by accident: the conversion to 
UTF-16 preserves them, perhaps incorrectly so,  but the NS libs display them as 
a distinctive and very suggestive glyph. Apparently [NSString 
stringWithCharacters:] doesn't perform any validation at all.

On the other hand, I think we still do need a subroutine for converting to 
UTF-8 for passing strings to system code where graceful handling of invalid 
encoding cannot be assumed, as there appears to be nothing in Emacs that can do 
this.

> +  encoded_name = code_convert_string_norecord (name, Qutf_16le, 1);

Presumably this should be utf_16be on big-endian platforms. We still support 
PowerPC macOS, don't we?

> +  str = [NSString stringWithCharacters: (const unichar *) SDATA 
> (encoded_name)

Is SDATA guaranteed to be 16-bit aligned? Doesn't matter on x86 or PowerPC, but 
strictly speaking...