bug#48902: 28.0.50; Directory names containing apostrophes and backticks cause problems

[Eli Zaretskii]

> Date: Tue, 8 Jun 2021 13:12:56 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: 48902@debbugs.gnu.org, Rudolf Adamkovič <salutis@me.com>,
>  naofumi@yasufuku.dev
> 
> On Tue, Jun 08, 2021 at 01:57:01PM +0200, Lars Ingebrigtsen wrote:
> > naofumi@yasufuku.dev <naofumi@yasufuku.dev> writes:
> > 
> > > diff --git a/src/nsimage.m b/src/nsimage.m
> > > index fa81a41a51..8c7a3d9a09 100644
> > > --- a/src/nsimage.m
> > > +++ b/src/nsimage.m
> > > @@ -262,7 +262,7 @@ + (instancetype)allocInitFromFile: (Lisp_Object)file
> > >    found = ENCODE_FILE (found);
> > >  
> > >    image = [[EmacsImage alloc] initByReferencingFile:
> > > -                     [NSString stringWithLispString: found]];
> > > +                     [NSString stringWithUTF8String: SSDATA (found)]];
> > 
> > Hm...  I'm not very familiar at all with the Objective C code here...
> > but shouldn't "found" here be a Lisp string so that stringWithLispString
> > would do the right thing?
> 
> It's always possible that stringWithLispString isn't doing the right
> thing. It's implemented at nsfns.m:3026. I know almost nothing about
> UTF8/UTF16 so while it looks like it's doing the right thing to me, I
> could be entirely wrong.

It looks like stringWithLispString encodes into UTF-16?  But file
names on macOS should be encoded in UTF-8, and in fact
allocInitFromFile already does TRT when it calls ENCODE_FILE, just
before stringWithLispString is called.  So I think the patch is
correct.

(UTF-16 encoding on macOS is for ENCODE_SYSTEM, right?)