bug#38287: 26.3.50; filenotify.el: the Chinese file name in the event is messy code

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: netjune@outlook.com,  38287@debbugs.gnu.org
> Date: Wed, 20 Nov 2019 18:49:34 +0100
> 
> > The strings shown in the image are UTF-8 encoded.
> 
> Hmm. kqueue.c is very lazy in using ENCODE_FILE, it uses it only in
> kqueue-add-watch. Maybe it is missing somewhere else?

I see one potential problem: in kqueue-add-watch, you encode the file
name, but then pass it to APIs that generally expect multibyte
(i.e. un-encoded) strings, although they will also work with encoded
unibyte strings.  Moreover, you put the unibyte encoded file name into
the watch object.  Not sure if this is related to the issue at hand,
but it would be cleaner to make this change:

diff --git a/src/kqueue.c b/src/kqueue.c
index 76d7fc1..1383d7d 100644
--- a/src/kqueue.c
+++ b/src/kqueue.c
@@ -414,7 +414,7 @@ DEFUN ("kqueue-add-watch", Fkqueue_add_watch, 
Skqueue_add_watch, 3, 3, 0,
     }
 
   /* Open file.  */
-  file = ENCODE_FILE (file);
+  Lisp_Object encoded_file = ENCODE_FILE (file);
   oflags = O_NONBLOCK;
 #if O_EVTONLY
   oflags |= O_EVTONLY;
@@ -426,7 +426,7 @@ DEFUN ("kqueue-add-watch", Fkqueue_add_watch, 
Skqueue_add_watch, 3, 3, 0,
 #else
     oflags |= O_NOFOLLOW;
 #endif
-  fd = emacs_open (SSDATA (file), oflags, 0);
+  fd = emacs_open (SSDATA (encoded_file), oflags, 0);
   if (fd == -1)
     report_file_error ("File cannot be opened", file);
 
Btw, I don't think I understand the nature of the problem yet: where
were the unibyte strings shown in the report printed?  Did some Emacs
code print them, and if so, where is that code?