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 #11 received at 49723 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Federico Tedin <federicotedin <at> gmail.com>
Cc: phst <at> google.com, 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: Tue, 14 Sep 2021 22:24:22 +0300

> From: Federico Tedin <federicotedin <at> gmail.com>
> Cc: 49723 <at> debbugs.gnu.org,  Philipp Stephani <phst <at> google.com>
> Date: Tue, 14 Sep 2021 21:01:16 +0200
> 
> I'm interested in looking into this one since I want to learn more about
> the C side of the codebase. However, I wasn't able to find a call to
> expand-file-name in encode_file_name or encode_file_name_1. I did find
> the null byte check though (CHECK_TYPE + memchr). Maybe I am missing
> something out.

My description was inaccurate: the expand-file-name call usually
precedes the call to ENCODE_FILE, it is not part of encode_file_name.

> I assume that a similar check on expand-file-name should be applied to
> both input arguments, NAME and DEFAULT-DIRECTORY?

I don't think we need that because expand-file-name calls itself on
DEFAULT-DIRECTORY internally.  But we may need to perform the check on
default-directory, if we use it inside expand-file-name.

Previous Next

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