GNU bug report logs - #49723
28.0.50; Test in coding.c for NUL bytes in filenames is not reliable

Previous Next

Full log

Message #41 received at 49723 <at> debbugs.gnu.org (full text, mbox):

From: Federico Tedin <federicotedin <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: phst <at> google.com, Eli Zaretskii <eliz <at> gnu.org>, 49723 <at> debbugs.gnu.org
Subject: Re: bug#49723: 28.0.50; Test in coding.c for NUL bytes in filenames
 is not reliable
Date: Thu, 16 Sep 2021 21:13:04 +0200

Michael Albinus <michael.albinus <at> gmx.de> writes:

> I haven't checked yet what's needed. However, there are several
> incarnations of `expand-file-name' implementation in Tramp, namely
>
> grep --color=auto -nH --null -E 'defun.+handle-expand-file-name' *.el
> tramp.el3393:(defun tramp-handle-expand-file-name (name &optional dir)
> tramp-gvfs.el1137:(defun tramp-gvfs-handle-expand-file-name (name &optional dir)
> tramp-sh.el2683:(defun tramp-sh-handle-expand-file-name (name &optional dir)
> tramp-smb.el736:(defun tramp-smb-handle-expand-file-name (name &optional dir)
> tramp-sudoedit.el346:(defun tramp-sudoedit-handle-expand-file-name (name &optional dir)
>
> Best regards, Michael.

Ouch, hadn't noticed those. I gave a look at the four I hadn't seen (gvfs,
sh, smb and sudoedit) and it seems like all of them return expressions
in the shape of:

  (expand-file-name xyz)

or:

  (tramp-run-real-handler #'expand-file-name xyz)

with xyz being a value derived from NAME or NAME and DIR. So in that
case it seems like we would be covered by the changes in `expand-file-mode`.

Previous Next

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