bug#36507: 27.0.50; Crash on evaluating invalid UTF-8 byte sequence on MacOS

[YAMAMOTO Mitsuharu]

On Fri, 05 Jul 2019 20:36:34 +0900,
Stefan Kangas wrote:
> 
> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
> > > >   (decode-coding-string "\xE3\x32\x9A\x36" 'chinese-gb18030)
> > >
> > > I think the issue as such is beyond me, but I can reproduce this every 
> > > time.
> > > Please let me know if you need help testing or more information.
> > >
> > > Before crash, I get this output:
> > > Thread 1 received signal SIGSEGV, Segmentation fault.
> > > 0x00007fff8ddbd326 in CFCharacterSetIsLongCharacterMember () from
> > > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
> >
> > Please try the patch below.
> 
> The patch works; I no longer get the crash.  The return value is now:
> 
>     "#(" " 0 1 (charset gb18030-4-byte-ext-2))"

Thanks.  I pushed the patch to master and the emacs-26 branch as
0e15bd11dc0 and f0db687a285, respectively.  (I forgot to add the bug
ID to commit log for the former.)  Closing the bug.

> Note that the " " is a visually wide white space character that I
> can't copy to other programs for some reason.  It is here replaced
> with a space.  Not sure if this is expected or not.

On the Mac port, from which macfont.m originally came, the character
is displayed with boxed hexadecimal.  So, this would be another issue
specific to the NS port.

                                     YAMAMOTO Mitsuharu
                                mituharu@math.s.chiba-u.ac.jp