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

[Eli Zaretskii]

> From: Mattias Engdegård <mattiase@acm.org>
> Date: Thu, 20 Aug 2020 20:46:17 +0200
> Cc: alan@idiocy.org, 42904@debbugs.gnu.org
> 
> 20 aug. 2020 kl. 15.24 skrev Eli Zaretskii <eliz@gnu.org>:
> 
> > What would you like xdisp.c to do instead in this case?  If there's an
> > alternative way of dealing with such frame titles that is better in
> > some sense, we could either adopt it for all platforms, or only for
> > NS.
> 
> Not sure how to deal with it, but maybe it's just a matter of settling on 
> multibyte representation when building the title (as in mode_line_noprop_buf 
> and so on)?

I don't think I understand.  mode_line_noprop_buf gets the bytes, and
then we call make_string on it, so the result is the same as the one
you'd like to avoid.  Or am I missing something?

By "settling on multibyte representation", do you mean that we should
convert raw bytes to their multibyte form?  Or do you mean something
else?

> I presume that the current ambiguity comes from when there were good reasons 
> to build these strings in various unibyte encodings, but maybe it isn't 
> motivated today?

Again, what would you like to have instead?  Would calling
str_as_multibyte do what you want?

The reason we build a unibyte string is that the presence of raw bytes
generally means a unibyte string is desired; it's a heuristic.  It is
also the simplest thing to do in this case, and always works because
it doesn't change the byte sequence of the original string.

> If it is at all any trouble at all, just leave it as it is. On the other 
> hand, perhaps we have found a way to simplify the code by accident.

See above: maybe str_as_multibyte is what you want?