GNU bug report logs - #48902
28.0.50; Directory names containing apostrophes and backticks cause problems

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 48902 <at> debbugs.gnu.org, larsi <at> gnus.org, salutis <at> me.com, naofumi <at> yasufuku.dev
Subject: bug#48902: 28.0.50; Directory names containing apostrophes and backticks cause problems
Date: Tue, 08 Jun 2021 17:02:25 +0300

> Date: Tue, 8 Jun 2021 14:00:17 +0100
> From: Alan Third <alan <at> idiocy.org>
> Cc: larsi <at> gnus.org, naofumi <at> yasufuku.dev, 48902 <at> debbugs.gnu.org,
> 	salutis <at> me.com
> 
> > 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?)
> 
> I think you're right. But confusingly initByReferencingFile takes an
> NSString which is a UTF-16 format string, so if I remove all the calls
> to ENCODE_FILE, stringWithLispString works fine.
> 
> I guess we just need to make a note that stringWithLispString cannot
> handle UTF-8 encoded filenames, unless someone has a smarter solution.

If you do need a UTF-16 encoded string, then instead of ENCODE_FILE
you can call code_convert_string_norecord with Qutf_16.  There's no
need to invent or use a private UTF-16 encoder there, and you also get
rid of an unnecessary extra UTF-8 encoding as a bonus.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.