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

[Alan Third]

On Tue, Jun 08, 2021 at 09:09:51PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 8 Jun 2021 17:19:44 +0100
> > From: Alan Third <alan@idiocy.org>
> > Cc: larsi@gnus.org, naofumi@yasufuku.dev, 48902@debbugs.gnu.org,
> >     salutis@me.com
> > 
> > In this case the call to ENCODE_FILE in allocInitFromFile is actually
> > redundant because image_find_image_fd already calls ENCODE_FILE on the
> > filename before passing it back. So we get a UTF-8 string no matter
> > what.
> 
> Then why was the code re-encoding t in UTF-16?  A bug?

No, sorry, I'm not being clear. The internal format of NSString is
UTF-16. We can load practically anything into it, as long as we know
ahead of time what the encoding is.

> > NSString can read in almost anything, and Mattias extended it to read
> > in multibyte (and ascii) lisp strings, so we don't need a UTF-16 input
> > specifically. It would probably be nice if NSString was also able to
> > recognise that a lisp string is UTF-8 and handle that itself, but I
> > don't think that's really possible, unless we make the assumption that
> > any unibyte string it's passed will already be ascii or UTF-8.
> > 
> > I don't know if that's a reasonable assumption.
> 
> Any file name passed through ENCODE_FILE should be in UTF-8 on macOS,
> as I understand that's how the macOS filesystems work.  Am I mistaken?
> Can the value of default-file-name-coding-system on macOS be anything
> other than UTF-8?

Not as far as I'm aware. But NSString is used all over the place in
the NS port code base (and all through the toolkit). Any time we pass
a string to or from the toolkit it has to be converted to or from
NSString. I think most of the actual file access code in Emacs is low
level C code which won't go near NSString, though, so it's not worth
changing C code to make ObjC code cleaner.

I guess I'm just being lazy and would like our extensions to NSString
to just DTRT, but it seems that's impractical. :)
-- 
Alan Third