From unknown Thu Aug 14 17:27:56 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#49723 <49723@debbugs.gnu.org> To: bug#49723 <49723@debbugs.gnu.org> Subject: Status: 28.0.50; Test in coding.c for NUL bytes in filenames is not reliable Reply-To: bug#49723 <49723@debbugs.gnu.org> Date: Fri, 15 Aug 2025 00:27:56 +0000 retitle 49723 28.0.50; Test in coding.c for NUL bytes in filenames is not r= eliable reassign 49723 emacs submitter 49723 Eli Zaretskii severity 49723 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 24 13:39:38 2021 Received: (at submit) by debbugs.gnu.org; 24 Jul 2021 17:39:38 +0000 Received: from localhost ([127.0.0.1]:46886 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m7Lcg-0001aD-Dr for submit@debbugs.gnu.org; Sat, 24 Jul 2021 13:39:38 -0400 Received: from lists.gnu.org ([209.51.188.17]:36456) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m7Lcf-0001a6-BN for submit@debbugs.gnu.org; Sat, 24 Jul 2021 13:39:37 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37926) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m7Lcf-0000tv-3W for bug-gnu-emacs@gnu.org; Sat, 24 Jul 2021 13:39:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46552) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m7Lce-0004wT-RG; Sat, 24 Jul 2021 13:39:36 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4846 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m7Lce-0006eT-Cd; Sat, 24 Jul 2021 13:39:36 -0400 Date: Sat, 24 Jul 2021 20:39:22 +0300 Message-Id: <83o8ary5kl.fsf@gnu.org> From: Eli Zaretskii To: bug-gnu-emacs@gnu.org Subject: 28.0.50; Test in coding.c for NUL bytes in filenames is not reliable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: submit Cc: Philipp Stephani X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) From: eliz@HOME-C4E4A596F7.i-did-not-set--mail-host-address--so-tickle-me --text follows this line-- Emacs currently tries to catch null bytes in file names in encode_file_name, after encoding the file name. But that is not reliable enough, because it assumes that the call to expand-file-name at the beginning of encode_file_name leaves those null bytes intact. That is not guaranteed, and in fact doesn't happen at least on MS-Windows: the file name gets chopped after the first null byte, and doesn't trigger the test in encode_file_name. So for a more reliable test we need to include such a check inside expand-file-name (and then we could probably drop the test in encode_file_name, because Emacs always runs file names through expand-file-name before using them). In GNU Emacs 28.0.50 (build 1573, i686-pc-mingw32) of 2021-07-24 built on HOME-C4E4A596F7 Repository revision: 7c83e605ab84e8b62254c55f347abc8aa9c6057b Repository branch: master Windowing system distributor 'Microsoft Corp.', version 5.1.2600 System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600) Configured using: 'configure -C --prefix=/d/usr --with-wide-int --with-modules --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3'' Configured features: ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XPM ZLIB Important settings: value of $LANG: ENU locale-coding-system: cp1255 Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json map text-property-search time-date subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty make-network-process emacs) Memory information: ((conses 16 56888 7103) (symbols 48 7785 1) (strings 16 21560 2884) (string-bytes 1 630636) (vectors 16 13320) (vector-slots 8 173301 9720) (floats 8 23 47) (intervals 40 265 116) (buffers 888 10)) From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 14 15:01:26 2021 Received: (at 49723) by debbugs.gnu.org; 14 Sep 2021 19:01:26 +0000 Received: from localhost ([127.0.0.1]:50189 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQDgM-00088A-Gy for submit@debbugs.gnu.org; Tue, 14 Sep 2021 15:01:26 -0400 Received: from mail-wr1-f47.google.com ([209.85.221.47]:41570) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQDgK-00087w-CM for 49723@debbugs.gnu.org; Tue, 14 Sep 2021 15:01:25 -0400 Received: by mail-wr1-f47.google.com with SMTP id w29so21110230wra.8 for <49723@debbugs.gnu.org>; Tue, 14 Sep 2021 12:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=pFDmv4Fa0s8HVdU6zDLOafF7I8+VIJ1FIjxA3Ckn5WU=; b=j4bdP8/BL9OWB25uEhw6TNULy/AuK9tCCTkRsQoFPsdAM69B0TdTnUl4iwKY9Zfq1R lPbvBqdmqtGr79BeJVtisgFk2FKchh9C/CnY5nc5lCzpsvQKmNj42F8d3UFaBAnjNcxw HfWggLjEwQxETstmS0/a2BJfKX8RYQQ5gBYrVsVkhIVKdT1R3DuIs11a/Ys8K6b3dRS9 JeJ9Y9L2rDDdjy0ze1y8K1OX4+R/YxsBZETdPsDtO14/hvdvByMeIM9SlS6oZZj2DfAF BK3wdPZfyCNye+B56pN7gjjxEYIbfyYTpUVYWD5n8Y8IyR7gQ6no1Qt1pJ+BiDPWda4V 39Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=pFDmv4Fa0s8HVdU6zDLOafF7I8+VIJ1FIjxA3Ckn5WU=; b=fCBZDGx5MBuhTAvLml5PsZWCO9an0ZIeryONrJw69TEV7LMymKnYlMs2Aef6JvceMy jrZ/hsZG+ENT8TLoT5tgsPf+jjoTAYg3HyVlVwL5YraYNCfUoI7DN//4QiJ7xhv6kP7D B4WZMlCuhPpG7Qe1x1Swn+P1LuqTxR5ngeL0Pke7Fr7dnySCR7y+iszu2MVUTOFj8DIH BTgURMdkEbJa28SAVBv0lTV9dthRDgTbw/xaWKS+cAndzy4F17Bd1/p9gob6XsTxDym6 Ot1G/fhP+WyNBLZHHlr1jhS0GlMDlGHAlXkrju6RWQqgOCbTMsTECpxUM5bGjK1l6lAP ltBw== X-Gm-Message-State: AOAM533FKlCAf7Dfk0SKIZ05k2VmMttdTdbWcr4McheKhj4oIq15F+UM 6ajTqOrBbJYCo7sBC/+Ivuo= X-Google-Smtp-Source: ABdhPJxQr4awv2hpkmY4NAXMpsG+tY+CVFuHfkaYKye0fkUPMIULKwm870OVeE5e9864voWBwpA1Zw== X-Received: by 2002:a5d:48c5:: with SMTP id p5mr695978wrs.303.1631646078261; Tue, 14 Sep 2021 12:01:18 -0700 (PDT) Received: from seele (ip5b4202e5.dynamic.kabel-deutschland.de. [91.66.2.229]) by smtp.gmail.com with ESMTPSA id m4sm13159519wrx.81.2021.09.14.12.01.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Sep 2021 12:01:17 -0700 (PDT) From: Federico Tedin To: Eli Zaretskii Subject: Re: bug#49723: 28.0.50; Test in coding.c for NUL bytes in filenames is not reliable References: <83o8ary5kl.fsf@gnu.org> Date: Tue, 14 Sep 2021 21:01:16 +0200 In-Reply-To: <83o8ary5kl.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 24 Jul 2021 20:39:22 +0300") Message-ID: <87pmtbj81v.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 49723 Cc: Philipp Stephani , 49723@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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. I assume that a similar check on expand-file-name should be applied to both input arguments, NAME and DEFAULT-DIRECTORY? Thanks! Eli Zaretskii writes: > From: eliz@HOME-C4E4A596F7.i-did-not-set--mail-host-address--so-tickle-me > --text follows this line-- > Emacs currently tries to catch null bytes in file names in > encode_file_name, after encoding the file name. But that is not > reliable enough, because it assumes that the call to expand-file-name > at the beginning of encode_file_name leaves those null bytes intact. > That is not guaranteed, and in fact doesn't happen at least on > MS-Windows: the file name gets chopped after the first null byte, and > doesn't trigger the test in encode_file_name. > > So for a more reliable test we need to include such a check inside > expand-file-name (and then we could probably drop the test in > encode_file_name, because Emacs always runs file names through > expand-file-name before using them). > > In GNU Emacs 28.0.50 (build 1573, i686-pc-mingw32) > of 2021-07-24 built on HOME-C4E4A596F7 > Repository revision: 7c83e605ab84e8b62254c55f347abc8aa9c6057b > Repository branch: master > Windowing system distributor 'Microsoft Corp.', version 5.1.2600 > System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600) > > Configured using: > 'configure -C --prefix=/d/usr --with-wide-int --with-modules > --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3'' > > Configured features: > ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY > W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XPM > ZLIB > > Important settings: > value of $LANG: ENU > locale-coding-system: cp1255 > > Major mode: Lisp Interaction > > Minor modes in effect: > tooltip-mode: t > global-eldoc-mode: t > eldoc-mode: t > electric-indent-mode: t > mouse-wheel-mode: t > tool-bar-mode: t > menu-bar-mode: t > file-name-shadow-mode: t > global-font-lock-mode: t > font-lock-mode: t > blink-cursor-mode: t > auto-composition-mode: t > auto-encryption-mode: t > auto-compression-mode: t > line-number-mode: t > indent-tabs-mode: t > transient-mark-mode: t > > Load-path shadows: > None found. > > Features: > (shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs > rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail > rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs > eieio-loaddefs password-cache json map text-property-search time-date > subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies > mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs > cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils > iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks > lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win > w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe > tabulated-list replace newcomment text-mode elisp-mode lisp-mode > prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu > timer select scroll-bar mouse jit-lock font-lock syntax font-core > term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang > misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms > cp51932 hebrew greek romanian slovak czech european ethiopic indian > cyrillic chinese composite charscript charprop case-table epa-hook > jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button > loaddefs faces cus-face macroexp files window text-properties overlay > sha1 md5 base64 format env code-pages mule custom widget > hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty > make-network-process emacs) > > Memory information: > ((conses 16 56888 7103) > (symbols 48 7785 1) > (strings 16 21560 2884) > (string-bytes 1 630636) > (vectors 16 13320) > (vector-slots 8 173301 9720) > (floats 8 23 47) > (intervals 40 265 116) > (buffers 888 10)) From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 14 15:24:37 2021 Received: (at 49723) by debbugs.gnu.org; 14 Sep 2021 19:24:37 +0000 Received: from localhost ([127.0.0.1]:50205 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQE2n-0000DL-5D for submit@debbugs.gnu.org; Tue, 14 Sep 2021 15:24:37 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51986) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQE2l-0000D9-BZ for 49723@debbugs.gnu.org; Tue, 14 Sep 2021 15:24:35 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:35874) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mQE2f-0005S2-Gc; Tue, 14 Sep 2021 15:24:29 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2057 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mQE2f-0007oi-0b; Tue, 14 Sep 2021 15:24:29 -0400 Date: Tue, 14 Sep 2021 22:24:22 +0300 Message-Id: <8335q7c655.fsf@gnu.org> From: Eli Zaretskii To: Federico Tedin In-Reply-To: <87pmtbj81v.fsf@gmail.com> (message from Federico Tedin on Tue, 14 Sep 2021 21:01:16 +0200) Subject: Re: bug#49723: 28.0.50; Test in coding.c for NUL bytes in filenames is not reliable References: <83o8ary5kl.fsf@gnu.org> <87pmtbj81v.fsf@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49723 Cc: phst@google.com, 49723@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Federico Tedin > Cc: 49723@debbugs.gnu.org, Philipp Stephani > 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 14 18:17:45 2021 Received: (at 49723) by debbugs.gnu.org; 14 Sep 2021 22:17:45 +0000 Received: from localhost ([127.0.0.1]:50342 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQGkL-0004N4-CX for submit@debbugs.gnu.org; Tue, 14 Sep 2021 18:17:45 -0400 Received: from mail-wr1-f47.google.com ([209.85.221.47]:39897) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQGkG-0004Mo-SF for 49723@debbugs.gnu.org; Tue, 14 Sep 2021 18:17:44 -0400 Received: by mail-wr1-f47.google.com with SMTP id u15so629930wru.6 for <49723@debbugs.gnu.org>; Tue, 14 Sep 2021 15:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=qeni89jRY1r4tzI516tbSKXQONFdIy1IM6dXfzgkjDo=; b=Wya4TW6FNVT3K8AG2cJipMcQgimX3m2R+dI+6GiS9RP1MN+DFtTSLbK/tlQ7DBmdeC WNODY+RKNo5rQZfVqBgTBbbPOUC7ZMedRKuyTPjr5XjH7P0zEsJXWQ8SFtZS1ZikeELH 2+Lwe5EWFivpKcLcYEpL17pc5nugcRSXzRPBvtpINajWcu2z7gtP5q6oX/0bfP5vI3P5 NmLbl0E9/cWnYwP2ycWJmt6tjc4HQhJMrC9Z6bD2+PaaDR2Cg5yDZpHBADliJAC+RplT asYKIWE4KtmPU9p8ot2+YxSkoD/+Ex/dP2vYXkfijelJ9xwmkVPlZW5zGOkFNNOMBZou OR/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=qeni89jRY1r4tzI516tbSKXQONFdIy1IM6dXfzgkjDo=; b=WQodAaREdj3SBRUQOe1hNlYC2svhpj37eEF49VwFSTjf9jIv6vmoH+PgP2xBuOA2bf iMwykojbDGw4NEQ6Xkh9mQLmjRXCaq+JZr8kakSbI5qxEoSFBUiLNSAPj+K92pXDd0ny G0Y0T3QbehbF+YNJ38BUWh7yPqfH1JXdC4IdN3/giPXpN9hNaXkCnLZUnHB7Zk6kUKRE fuCU9u3aN3iafRU5JCHgE2O1/SPGMoDyj7KwFzHOkOKSNJS6uMfnGVqzHlRgTP4fpjUd tEAzO0tGNf5K9eqD/tE/bi8HsDomfzOxZwEC5uOstHs+kMIQiVga0lPdems1024xCYGb 4+og== X-Gm-Message-State: AOAM532Se8Kyx1lNu4H51El+rlzk2fYD6dUYfCFTpbVQamyUgIHymOKV jRKKpIAf+9/3h/upfi2xdIrS/IFcqWI= X-Google-Smtp-Source: ABdhPJxtyqo5c9eZgx12+GuGGPJKiFri8TfyT3VnwqjeEq2bCmEo0rBN9zEGdMzInDS/+8XA840Fvw== X-Received: by 2002:a5d:46cb:: with SMTP id g11mr1472347wrs.60.1631657854675; Tue, 14 Sep 2021 15:17:34 -0700 (PDT) Received: from gehirn (ip5b4202e5.dynamic.kabel-deutschland.de. [91.66.2.229]) by smtp.gmail.com with ESMTPSA id t1sm2505012wrz.39.2021.09.14.15.17.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Sep 2021 15:17:34 -0700 (PDT) From: Federico Tedin To: Eli Zaretskii Subject: Re: bug#49723: 28.0.50; Test in coding.c for NUL bytes in filenames is not reliable References: <83o8ary5kl.fsf@gnu.org> <87pmtbj81v.fsf@gmail.com> <8335q7c655.fsf@gnu.org> Date: Wed, 15 Sep 2021 00:17:33 +0200 In-Reply-To: <8335q7c655.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 14 Sep 2021 22:24:22 +0300") Message-ID: <87pmta6buq.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 49723 Cc: phst@google.com, 49723@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Ok! Here's my first try at this. I ended up skipping the check on DEFAULT-DIRECTORY since as you mentioned, its value is used with expand-file-name itself. In the other case, if default-directory is picked up, then I checked the value of that variable. --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=expand-file-name.patch Content-Description: patch >From 0f960aeab1c4b3182d597ac0ce80526f09e97452 Mon Sep 17 00:00:00 2001 From: Federico Tedin Date: Wed, 15 Sep 2021 00:15:16 +0200 Subject: [PATCH] Add null byte checks to filenames in expand-file-name (bug#49723) * src/fileio.c (expand-file-name): Check for null bytes for both NAME and DEFAULT-DIRECTORY arguments. Also check for null bytes in buffer-local default-directory, assuming it is used. * src/coding.c (encode_file_name): Use CHECK_STRING_NULL_BYTES. * src/lisp.h (CHECK_STRING_NULL_BYTES): Add function for checking for null bytes in Lisp strings. * test/src/fileio-tests.el (fileio-test--expand-file-name-null-bytes): Add test for new changes to expand-file-name. * etc/NEWS: Announce changes. --- etc/NEWS | 6 ++++++ src/coding.c | 3 +-- src/fileio.c | 6 +++++- src/lisp.h | 7 +++++++ test/src/fileio-tests.el | 9 +++++++++ 5 files changed, 28 insertions(+), 3 deletions(-) diff --git a/etc/NEWS b/etc/NEWS index 5809716868..8d96ceff79 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -278,6 +278,12 @@ personalize the uniquified buffer name. --- ** 'remove-hook' is now an interactive command. +** 'expand-file-name' now checks for null bytes in filenames. +The function will now check for null bytes in both NAME and +DEFAULT-DIRECTORY arguments, as well as in the 'default-directory' +buffer-local variable, assuming its value is used. + +--- ** Frames +++ diff --git a/src/coding.c b/src/coding.c index d027c7d539..7030a53869 100644 --- a/src/coding.c +++ b/src/coding.c @@ -10430,8 +10430,7 @@ encode_file_name (Lisp_Object fname) cause subtle bugs because the system would silently use a different filename than expected. Perform this check after encoding to not miss NUL bytes introduced through encoding. */ - CHECK_TYPE (memchr (SSDATA (encoded), '\0', SBYTES (encoded)) == NULL, - Qfilenamep, fname); + CHECK_STRING_NULL_BYTES (encoded); return encoded; } diff --git a/src/fileio.c b/src/fileio.c index 0db8ed793b..3c13d3fe41 100644 --- a/src/fileio.c +++ b/src/fileio.c @@ -945,6 +945,7 @@ DEFUN ("expand-file-name", Fexpand_file_name, Sexpand_file_name, 1, 2, 0, USE_SAFE_ALLOCA; CHECK_STRING (name); + CHECK_STRING_NULL_BYTES (name); /* If the file name has special constructs in it, call the corresponding file name handler. */ @@ -993,7 +994,10 @@ DEFUN ("expand-file-name", Fexpand_file_name, Sexpand_file_name, 1, 2, 0, if (STRINGP (dir)) { if (file_name_absolute_no_tilde_p (dir)) - default_directory = dir; + { + CHECK_STRING_NULL_BYTES (dir); + default_directory = dir; + } else { Lisp_Object absdir diff --git a/src/lisp.h b/src/lisp.h index 7bfc69b647..9716b34bae 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -1615,6 +1615,13 @@ STRING_SET_CHARS (Lisp_Object string, ptrdiff_t newsize) XSTRING (string)->u.s.size = newsize; } +INLINE void +CHECK_STRING_NULL_BYTES (Lisp_Object string) +{ + CHECK_TYPE (memchr (SSDATA (string), '\0', SBYTES (string)) == NULL, + Qfilenamep, string); +} + /* A regular vector is just a header plus an array of Lisp_Objects. */ struct Lisp_Vector diff --git a/test/src/fileio-tests.el b/test/src/fileio-tests.el index f4d123b426..438ebebb76 100644 --- a/test/src/fileio-tests.el +++ b/test/src/fileio-tests.el @@ -136,6 +136,15 @@ fileio-tests--relative-default-directory (should (and (file-name-absolute-p name) (not (eq (aref name 0) ?~)))))) +(ert-deftest fileio-test--expand-file-name-null-bytes () + "Test that expand-file-name checks for null bytes in filenames." + (should-error (expand-file-name (concat "file" (char-to-string ?\0) ".txt")) + :type 'wrong-type-argument) + (should-error (expand-file-name "file.txt" (concat "dir" (char-to-string ?\0))) + :type 'wrong-type-argument) + (let ((default-directory (concat "dir" (char-to-string ?\0)))) + (should-error (expand-file-name "file.txt") :type 'wrong-type-argument))) + (ert-deftest fileio-tests--file-name-absolute-p () "Test file-name-absolute-p." (dolist (suffix '("" "/" "//" "/foo" "/foo/" "/foo//" "/foo/bar")) -- 2.25.1 --=-=-= Content-Type: text/plain Eli Zaretskii writes: >> From: Federico Tedin >> Cc: 49723@debbugs.gnu.org, Philipp Stephani >> 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. --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 16 08:25:48 2021 Received: (at 49723) by debbugs.gnu.org; 16 Sep 2021 12:25:48 +0000 Received: from localhost ([127.0.0.1]:54053 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQqSZ-0002J4-Iv for submit@debbugs.gnu.org; Thu, 16 Sep 2021 08:25:47 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56226) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQqSX-0002Iq-8U for 49723@debbugs.gnu.org; Thu, 16 Sep 2021 08:25:46 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49338) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mQqSR-0005AO-Vo; Thu, 16 Sep 2021 08:25:39 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2055 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mQqSD-0008Vj-TN; Thu, 16 Sep 2021 08:25:38 -0400 Date: Thu, 16 Sep 2021 15:25:24 +0300 Message-Id: <837dfgaerv.fsf@gnu.org> From: Eli Zaretskii To: Federico Tedin In-Reply-To: <87pmta6buq.fsf@gmail.com> (message from Federico Tedin on Wed, 15 Sep 2021 00:17:33 +0200) Subject: Re: bug#49723: 28.0.50; Test in coding.c for NUL bytes in filenames is not reliable References: <83o8ary5kl.fsf@gnu.org> <87pmtbj81v.fsf@gmail.com> <8335q7c655.fsf@gnu.org> <87pmta6buq.fsf@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49723 Cc: phst@google.com, 49723@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Federico Tedin > Cc: phst@google.com, 49723@debbugs.gnu.org > Date: Wed, 15 Sep 2021 00:17:33 +0200 > > Ok! Here's my first try at this. I ended up skipping the check on > DEFAULT-DIRECTORY since as you mentioned, its value is used with > expand-file-name itself. In the other case, if default-directory is > picked up, then I checked the value of that variable. Thanks, this LGTM. > +** 'expand-file-name' now checks for null bytes in filenames. > +The function will now check for null bytes in both NAME and > +DEFAULT-DIRECTORY arguments, as well as in the 'default-directory' > +buffer-local variable, assuming its value is used. This should say that if null bytes are found, expand-file-name will signal an error. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 16 12:58:19 2021 Received: (at 49723) by debbugs.gnu.org; 16 Sep 2021 16:58:19 +0000 Received: from localhost ([127.0.0.1]:56432 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQuiI-0008Lk-Kd for submit@debbugs.gnu.org; Thu, 16 Sep 2021 12:58:19 -0400 Received: from mail-wm1-f50.google.com ([209.85.128.50]:52113) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQuiG-0008LU-BQ for 49723@debbugs.gnu.org; Thu, 16 Sep 2021 12:58:17 -0400 Received: by mail-wm1-f50.google.com with SMTP id y132so5312934wmc.1 for <49723@debbugs.gnu.org>; Thu, 16 Sep 2021 09:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=JoW9pCBZPXRzti24/EsF5AhAAANPaz6b9qpNjI7HTM4=; b=nJgGdqJUDm730OgHea2jZHj5JrJriLU5oFducKUOA+Pxtc1vraoq7+cQ4q82z0efPI Doh3QGbIscJbo7XejTqKec8kwH3gF5GTbH2rorIkPcxO1TM+/8E8DB0SV0na+qBv+C7u bQSEA2phj7Ou+E2G6U1KagoF2BjkPRj98xoelmOYvt73vePGmOSstavdMa2q2/1n8gfY DyZNi/RA/R1VarcVZyGrX6xKwGqqf+Nkpoil2BoumrxvDWHLRKGCkayYMqvknMb3LsHM yX1loz1iqTcL+OQQCDplojAD8QoKi0chXaq+CHrUwNXYNZ2lqr/llA6978txn1kZq6u7 Bmuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=JoW9pCBZPXRzti24/EsF5AhAAANPaz6b9qpNjI7HTM4=; b=H6TxC+BPQlQmHg+etpuFM8hNTRup+AZk9odtqrI4P46qkDWx+R3BJJPFbS99IMrgN4 sX3oQc4mBHiFA1Lm+tEd1DHBpcpjtdIUoInbe1OcELyROYwby45wFHGsTfqUwv6Kklxh rQmWmR3B4xoHXKRHioHIj8Ncksjg9LUihh/4+AaqTq+atWHxaM32jps1UrERyO4JC3V3 YrxKegDDfNIYGdkZ6r1VKtGMWVvQ+h0RKud3X6HKWCmJOWHlTko+OeJhi9uAW7Y85m+X 0Zd9ejlMNtIwDATb23cFHyVEmj+ykXxJ0+5Pxfdv6p8IsqADKj8UJvnLvZfjrQcAmFBg Cmdg== X-Gm-Message-State: AOAM532wgP2YQNgoJiLT/PVbOKtFg0cQeL76bpwrE4JTVveI0PCCqerr TzMQz/t52fS4U1XHS86Dv/ynkO5O9XM= X-Google-Smtp-Source: ABdhPJw3432C06Qt15fkMDAsxF6UCawWM+5lyEa4/0zswsjLcrhWBA6PAFln6cvqTnVIn/QEpjMiHQ== X-Received: by 2002:a7b:c052:: with SMTP id u18mr10925904wmc.105.1631811490204; Thu, 16 Sep 2021 09:58:10 -0700 (PDT) Received: from gehirn (ip5b4202e5.dynamic.kabel-deutschland.de. [91.66.2.229]) by smtp.gmail.com with ESMTPSA id i9sm8288361wmi.44.2021.09.16.09.58.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Sep 2021 09:58:09 -0700 (PDT) From: Federico Tedin To: Eli Zaretskii Subject: Re: bug#49723: 28.0.50; Test in coding.c for NUL bytes in filenames is not reliable References: <83o8ary5kl.fsf@gnu.org> <87pmtbj81v.fsf@gmail.com> <8335q7c655.fsf@gnu.org> <87pmta6buq.fsf@gmail.com> <837dfgaerv.fsf@gnu.org> Date: Thu, 16 Sep 2021 18:58:02 +0200 In-Reply-To: <837dfgaerv.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 16 Sep 2021 15:25:24 +0300") Message-ID: <8735q4zcdh.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 49723 Cc: phst@google.com, 49723@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Eli Zaretskii writes: >> +** 'expand-file-name' now checks for null bytes in filenames. >> +The function will now check for null bytes in both NAME and >> +DEFAULT-DIRECTORY arguments, as well as in the 'default-directory' >> +buffer-local variable, assuming its value is used. > > This should say that if null bytes are found, expand-file-name will > signal an error. Makes sense! I'm attaching a revised version. --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=expand-file-name.patch Content-Description: patch >From 6faba0f1107290d44a83d396a61747dea67f0f39 Mon Sep 17 00:00:00 2001 From: Federico Tedin Date: Wed, 15 Sep 2021 00:15:16 +0200 Subject: [PATCH] Add null byte checks to filenames in expand-file-name (bug#49723) * src/fileio.c (expand-file-name): Check for null bytes for both NAME and DEFAULT-DIRECTORY arguments. Also check for null bytes in buffer-local default-directory, assuming it is used. * src/coding.c (encode_file_name): Use CHECK_STRING_NULL_BYTES. * src/lisp.h (CHECK_STRING_NULL_BYTES): Add function for checking for null bytes in Lisp strings. * test/src/fileio-tests.el (fileio-test--expand-file-name-null-bytes): Add test for new changes to expand-file-name. * etc/NEWS: Announce changes. --- etc/NEWS | 7 +++++++ src/coding.c | 3 +-- src/fileio.c | 6 +++++- src/lisp.h | 7 +++++++ test/src/fileio-tests.el | 9 +++++++++ 5 files changed, 29 insertions(+), 3 deletions(-) diff --git a/etc/NEWS b/etc/NEWS index 17c42ce104..3484ef3f3f 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -281,6 +281,13 @@ personalize the uniquified buffer name. --- ** 'remove-hook' is now an interactive command. +** 'expand-file-name' now checks for null bytes in filenames. +The function will now check for null bytes in both NAME and +DEFAULT-DIRECTORY arguments, as well as in the 'default-directory' +buffer-local variable, assuming its value is used. If null bytes are +found, 'expand-file-name' will signal an error. + +--- ** Frames +++ diff --git a/src/coding.c b/src/coding.c index d027c7d539..7030a53869 100644 --- a/src/coding.c +++ b/src/coding.c @@ -10430,8 +10430,7 @@ encode_file_name (Lisp_Object fname) cause subtle bugs because the system would silently use a different filename than expected. Perform this check after encoding to not miss NUL bytes introduced through encoding. */ - CHECK_TYPE (memchr (SSDATA (encoded), '\0', SBYTES (encoded)) == NULL, - Qfilenamep, fname); + CHECK_STRING_NULL_BYTES (encoded); return encoded; } diff --git a/src/fileio.c b/src/fileio.c index 0db8ed793b..3c13d3fe41 100644 --- a/src/fileio.c +++ b/src/fileio.c @@ -945,6 +945,7 @@ DEFUN ("expand-file-name", Fexpand_file_name, Sexpand_file_name, 1, 2, 0, USE_SAFE_ALLOCA; CHECK_STRING (name); + CHECK_STRING_NULL_BYTES (name); /* If the file name has special constructs in it, call the corresponding file name handler. */ @@ -993,7 +994,10 @@ DEFUN ("expand-file-name", Fexpand_file_name, Sexpand_file_name, 1, 2, 0, if (STRINGP (dir)) { if (file_name_absolute_no_tilde_p (dir)) - default_directory = dir; + { + CHECK_STRING_NULL_BYTES (dir); + default_directory = dir; + } else { Lisp_Object absdir diff --git a/src/lisp.h b/src/lisp.h index 7bfc69b647..9716b34bae 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -1615,6 +1615,13 @@ STRING_SET_CHARS (Lisp_Object string, ptrdiff_t newsize) XSTRING (string)->u.s.size = newsize; } +INLINE void +CHECK_STRING_NULL_BYTES (Lisp_Object string) +{ + CHECK_TYPE (memchr (SSDATA (string), '\0', SBYTES (string)) == NULL, + Qfilenamep, string); +} + /* A regular vector is just a header plus an array of Lisp_Objects. */ struct Lisp_Vector diff --git a/test/src/fileio-tests.el b/test/src/fileio-tests.el index f4d123b426..438ebebb76 100644 --- a/test/src/fileio-tests.el +++ b/test/src/fileio-tests.el @@ -136,6 +136,15 @@ fileio-tests--relative-default-directory (should (and (file-name-absolute-p name) (not (eq (aref name 0) ?~)))))) +(ert-deftest fileio-test--expand-file-name-null-bytes () + "Test that expand-file-name checks for null bytes in filenames." + (should-error (expand-file-name (concat "file" (char-to-string ?\0) ".txt")) + :type 'wrong-type-argument) + (should-error (expand-file-name "file.txt" (concat "dir" (char-to-string ?\0))) + :type 'wrong-type-argument) + (let ((default-directory (concat "dir" (char-to-string ?\0)))) + (should-error (expand-file-name "file.txt") :type 'wrong-type-argument))) + (ert-deftest fileio-tests--file-name-absolute-p () "Test file-name-absolute-p." (dolist (suffix '("" "/" "//" "/foo" "/foo/" "/foo//" "/foo/bar")) -- 2.25.1 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 16 14:12:25 2021 Received: (at 49723) by debbugs.gnu.org; 16 Sep 2021 18:12:25 +0000 Received: from localhost ([127.0.0.1]:56522 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQvs1-00028e-CS for submit@debbugs.gnu.org; Thu, 16 Sep 2021 14:12:25 -0400 Received: from mout.gmx.net ([212.227.15.15]:51045) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQvrx-00028J-DK for 49723@debbugs.gnu.org; Thu, 16 Sep 2021 14:12:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1631815931; bh=vo+5tDygX1rxPHbIfH/gePZpN7wVxeWdoi+6s7WxpL8=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=Rxwnujxa8W4v1JKFl+Aq9Fg9+NdP7bU4akwUIRVXZZQIOzpu6DJDHSlCSN1OEM16e wcR00wdRH63o7J6gkY7GlEalDtcaW46wXlfvy6Fhwi8i8WkKajtH3Dfhqrs4Cqw7Mb MRWe4TzdX1vD/Hp9FV6Lu3IgHSvF+wx/4wzBzsBQ= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([213.220.158.132]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MYNJg-1mM6Y43qVu-00VS9m; Thu, 16 Sep 2021 20:12:11 +0200 From: Michael Albinus To: Federico Tedin Subject: Re: bug#49723: 28.0.50; Test in coding.c for NUL bytes in filenames is not reliable References: <83o8ary5kl.fsf@gnu.org> <87pmtbj81v.fsf@gmail.com> <8335q7c655.fsf@gnu.org> <87pmta6buq.fsf@gmail.com> <837dfgaerv.fsf@gnu.org> <8735q4zcdh.fsf@gmail.com> Date: Thu, 16 Sep 2021 20:12:09 +0200 In-Reply-To: <8735q4zcdh.fsf@gmail.com> (Federico Tedin's message of "Thu, 16 Sep 2021 18:58:02 +0200") Message-ID: <87tuikl79i.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:j1XEMTO7jAacQS4DZHNjBCxaZTy0UV8S7RA5MCMhtKuOwQevj7A W1OblN8oj15MUDDcQXEOqVNyz8Xp34dEBIilGCc5rL8AdVIJ0WtKsYlTXd+QvPa34fQ43Jj EvvnAb8TJ7T29HCSIRi2bQjgqC38cXxz/PjctuLX32EocvGvzuI0JqLprZD+0wPQnDivu96 YwWfQEsBZpujgPK7fgSog== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:VPGmX+KOIMI=:W8KQOtaslDjxtASHwTcuI2 7sD95k7c/+3eP+bM+yfziZMtfjo3wrjsXLmWpEqZzk16NDwiunEHqQu4+fRuGJ4UEiWaixSsj /TtmTE+Kj8t0ekSNziOYbA5GW1sDiyxsa70opZN0N2IwBEwxw6GnMRZ2mt+DM3I2ouVG+S3en xoFMw3CoafNy4mgcxtCA47nxohILx9DSBVBBTuXS+gMet9iCAV3jQkSGY6kuTGNraxnxqE+2I 5i0aiTP/H8WVRw3WTGhsg8DedFZQ94kzvYfCogipkTE+ZA6i7Buo1vL3jOyeJ5Pbg1EryDnNJ LVPbfM+zq09RoZ/q95bichaXPMuBPzTCAo1jeu5sTr8q3TV0QmmAyfOZzWWwbwXuESchUh04k ZdaX9HLqGOQ8OKmf9Jp4mUjDGGED6+PDq8d8o9MYeeSRl6Cj1jSQ/zm5XEQ0PjIT68vgty4jF /+8Mm8EJ9TiMqv5SKq/W/j8bIgEOgFqBxUYqCP9BqX7Joznk0JqCVE6yedMa4nbVHU9KlwmBK XyV3bkCyjajHy74+6JxUaG+V+s8Klj6ovuEkAHbWHtMwE9V3+Y1Xxx40opm2rzznsz7gGGKrP TZ0WO77tqDtgTIztkoX1qUcKZXSnj+kg5fmLW6AiCpCQPRk6Msz11PxOepLM3Bto109yxxCRg 2vrldxcpRS2wPcrlNVjz2Q9Iu9SqBFH30BNoz07iJ9+H3P0kE1LbnriqJviEZ58AYwWsAAPX0 GB1VsRD+B3b3/JaZ0Zf6CsXm6LJClViuYANNvTFnANIkTtBZpviZ+2cLhPlc0aVaBhlu8Q9Pn HsTLnIwhWe6SwlzILJxXF15WLX/YNZoEeF9VFSEixBFemxWxyJylD5MzWMqRHhblRSomUZNdc Vu8nPEv/VEZSRZhnRio/Lxe/AJuFvmcGiluQfFZFAP5xrRYbS563fMwMnPgvH8/Wiy3iEYHB8 BteGtN4xx6LIQDnBtaTm/dvlVXRTfpFdZAjAkHBsjTjm8pxpnlYHu3KRf0XTJUnjWtSpqw4DK gvU2J/TWTsw7xtD09q0hlRPoqCMI19JwgWW0jeur6IqBj/fCByclI0wMDavuhqYv4AZg9BTCs atee3jR5+T7pwU= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 49723 Cc: phst@google.com, Eli Zaretskii , 49723@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Federico Tedin writes: Hi, Sorry for being late, I have seen this just now only. > +** 'expand-file-name' now checks for null bytes in filenames. > +The function will now check for null bytes in both NAME and > +DEFAULT-DIRECTORY arguments, as well as in the 'default-directory' > +buffer-local variable, assuming its value is used. If null bytes are > +found, 'expand-file-name' will signal an error. Should this be implemented also in remote file names? Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 16 14:30:46 2021 Received: (at 49723) by debbugs.gnu.org; 16 Sep 2021 18:30:46 +0000 Received: from localhost ([127.0.0.1]:56541 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQw9l-0002fp-V2 for submit@debbugs.gnu.org; Thu, 16 Sep 2021 14:30:46 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35472) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQw9k-0002fW-5E for 49723@debbugs.gnu.org; Thu, 16 Sep 2021 14:30:44 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:60128) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mQw9e-0003TK-Hc; Thu, 16 Sep 2021 14:30:38 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4710 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mQw9R-0003jN-Ec; Thu, 16 Sep 2021 14:30:30 -0400 Date: Thu, 16 Sep 2021 21:30:18 +0300 Message-Id: <83v9308jb9.fsf@gnu.org> From: Eli Zaretskii To: Michael Albinus In-Reply-To: <87tuikl79i.fsf@gmx.de> (message from Michael Albinus on Thu, 16 Sep 2021 20:12:09 +0200) Subject: Re: bug#49723: 28.0.50; Test in coding.c for NUL bytes in filenames is not reliable References: <83o8ary5kl.fsf@gnu.org> <87pmtbj81v.fsf@gmail.com> <8335q7c655.fsf@gnu.org> <87pmta6buq.fsf@gmail.com> <837dfgaerv.fsf@gnu.org> <8735q4zcdh.fsf@gmail.com> <87tuikl79i.fsf@gmx.de> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49723 Cc: phst@google.com, 49723@debbugs.gnu.org, federicotedin@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Michael Albinus > Cc: Eli Zaretskii , phst@google.com, 49723@debbugs.gnu.org > Date: Thu, 16 Sep 2021 20:12:09 +0200 > > > +** 'expand-file-name' now checks for null bytes in filenames. > > +The function will now check for null bytes in both NAME and > > +DEFAULT-DIRECTORY arguments, as well as in the 'default-directory' > > +buffer-local variable, assuming its value is used. If null bytes are > > +found, 'expand-file-name' will signal an error. > > Should this be implemented also in remote file names? Are we sure remote file names cannot include null bytes? From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 16 14:38:29 2021 Received: (at 49723) by debbugs.gnu.org; 16 Sep 2021 18:38:29 +0000 Received: from localhost ([127.0.0.1]:56550 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQwHD-0002tZ-2y for submit@debbugs.gnu.org; Thu, 16 Sep 2021 14:38:28 -0400 Received: from mail-wm1-f45.google.com ([209.85.128.45]:51079) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQwGx-0002sy-6p for 49723@debbugs.gnu.org; Thu, 16 Sep 2021 14:38:25 -0400 Received: by mail-wm1-f45.google.com with SMTP id 140so5526934wma.0 for <49723@debbugs.gnu.org>; Thu, 16 Sep 2021 11:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=UMLY/VMqU8JyRGwC8cyu58yxr0pRQnVrl0bqVWkVoIk=; b=nOTu0N29IJMVsMPJBWOBD5dRQ+4/gxGwJrQFb2oJfD5YpyEU1ts1IyNYWcPjOOHSDV OuB2Gt3gMWJJmZb9OLGHxk8IueapROFEOTA+W2yZgChHoZ8dKCtolJY/TNYPdwuzt4oQ 0Ocjq9nDT2SwBVN9S2x2XuK3DWKQWtS0EX5x0nDvNWJ8Uj5wWdFVvvzCOSmLJ7CYel9u Lho4Q608Cqh9+bC6EH4WTOjs0kle9hiGI5p83dQRej9ErSK4UmNCduIBulhoBxzcMbrH upzvjFXsYRki1wR8UQ8AxSKkxtRT3R/xkK14Y9x4Qo4csSNiaXmi3fR4SkYFPgFFYp4F aYYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=UMLY/VMqU8JyRGwC8cyu58yxr0pRQnVrl0bqVWkVoIk=; b=2LT7oJFjYy0plQmyGea2nAci4UqibSxGAK3FI4FTmJhoTW04A+y5EdVGqHoUZgUxz5 7grYsbK7lnbcbBtH4u3Qg4qauYPaEOAD9COFP+pnRfjOgqxIgqmZeSHHX2U0bKSNHuoe vQzzHNkMcgczXve90VkIUOYfhKO7MVYrLXaSrcmplAI3dfDdnSZA7qKZ+JRQKuQJM3KU CE6TXM1l91ta4VELloZKnPUv4h9Do4sVErLz6yvptkuSyVwCQAD4ZYU8GcNyjHHwQ5pb fwQJMWiR/cCJcmdsjsoz3pUBv7jlOa29v+52jwM0SstfOsse93tVugHUgkeI66d+8YF8 na6w== X-Gm-Message-State: AOAM530v4JG4UG10J8potjZ80ov6Wow+Bk30XGuLovMPGbD+dLRGDMt3 0LRN9XtSxppiMAxCmjFR45dTHFYgXRhR7g== X-Google-Smtp-Source: ABdhPJzQ3vEmblBcHSwabc3/4xgqzH+HZeictIJFgMpu2IEod6WNGNXJ0/bFw/FxJS7mq54bffpANw== X-Received: by 2002:a05:600c:22d6:: with SMTP id 22mr6518977wmg.17.1631817484963; Thu, 16 Sep 2021 11:38:04 -0700 (PDT) Received: from gehirn (ip5b4202e5.dynamic.kabel-deutschland.de. [91.66.2.229]) by smtp.gmail.com with ESMTPSA id s13sm8432882wmc.47.2021.09.16.11.38.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Sep 2021 11:38:04 -0700 (PDT) From: Federico Tedin To: Michael Albinus Subject: Re: bug#49723: 28.0.50; Test in coding.c for NUL bytes in filenames is not reliable References: <83o8ary5kl.fsf@gnu.org> <87pmtbj81v.fsf@gmail.com> <8335q7c655.fsf@gnu.org> <87pmta6buq.fsf@gmail.com> <837dfgaerv.fsf@gnu.org> <8735q4zcdh.fsf@gmail.com> <87tuikl79i.fsf@gmx.de> Date: Thu, 16 Sep 2021 20:38:03 +0200 In-Reply-To: <87tuikl79i.fsf@gmx.de> (Michael Albinus's message of "Thu, 16 Sep 2021 20:12:09 +0200") Message-ID: <87y27wxt6c.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 49723 Cc: phst@google.com, Eli Zaretskii , 49723@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Michael Albinus writes: > Federico Tedin writes: > > Hi, > > Sorry for being late, I have seen this just now only. > >> +** 'expand-file-name' now checks for null bytes in filenames. >> +The function will now check for null bytes in both NAME and >> +DEFAULT-DIRECTORY arguments, as well as in the 'default-directory' >> +buffer-local variable, assuming its value is used. If null bytes are >> +found, 'expand-file-name' will signal an error. > > Should this be implemented also in remote file names? > > Best regards, Michael. Would this imply only doing it in `tramp-handle-expand-file-name`, or other functions as well? I had thought of doing it for at least `tramp-handle-expand-file-name`, but then I noticed that the function eventually calls `expand-file-name` with a combination of name + dir, or only with name. So in that case I figured that the null bytes check would be performed by `expand-file-name` anyways. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 16 14:44:49 2021 Received: (at 49723) by debbugs.gnu.org; 16 Sep 2021 18:44:49 +0000 Received: from localhost ([127.0.0.1]:56554 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQwNN-00035e-Gi for submit@debbugs.gnu.org; Thu, 16 Sep 2021 14:44:49 -0400 Received: from mout.gmx.net ([212.227.17.21]:51415) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQwNH-00035J-WC for 49723@debbugs.gnu.org; Thu, 16 Sep 2021 14:44:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1631817873; bh=IG4LaR30rG4tVX+hnQ6lkf41YkfRLT9mzls/DpvCT/8=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=MYXxIOO8RD96MdGhiy121vSfnva/tAok9pI5Y8kNqEf6i0S0KcAfmGrSa8euQSikU 1dYrRAM4q69xDxssW/imoHRpOn9Frx2QpzSy8hshxCgQRsu1DE1QxFIHmrm2t5QKe5 png3Wxn41MxYHWsrTrSTVLXl3Dxpl4bbT+eprV+g= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([213.220.158.132]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M6ll8-1mY5Vf1VB0-008HlK; Thu, 16 Sep 2021 20:44:33 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#49723: 28.0.50; Test in coding.c for NUL bytes in filenames is not reliable References: <83o8ary5kl.fsf@gnu.org> <87pmtbj81v.fsf@gmail.com> <8335q7c655.fsf@gnu.org> <87pmta6buq.fsf@gmail.com> <837dfgaerv.fsf@gnu.org> <8735q4zcdh.fsf@gmail.com> <87tuikl79i.fsf@gmx.de> <83v9308jb9.fsf@gnu.org> Date: Thu, 16 Sep 2021 20:44:32 +0200 In-Reply-To: <83v9308jb9.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 16 Sep 2021 21:30:18 +0300") Message-ID: <87pmt8l5rj.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:RSUTWh8K5mHFMWqLilFHAydF757HYZnC/P1qPDJw7+6hSsJ8R+q DvMB/fa4U/qcrrMGyQ4+7U5kJFkGEdorzckr0eQw9YFJbc/PnQAgpqRZ3zvjkbDN47PXzM1 Zo+KQz6lEhYrFDENQaxw4AfToKYoRiwAPjYlaZoXQ6mkP0+ZIAEXhsBpMwgBxqz2HLzzuIq P2ReW8WXRB/hlBI1zjYpw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:rJr2ZaapUy4=:CxgxZ9Ba6OzpRdwIajm9vj nTTuahel+p5vZyaM6QlUKdxjgrr5gIpDaRrMVEa/2RTqkc7vGCc7cL2A27aX77/5zqLe7T1Zb FbDhPHtOm5Hy67i3e8fP87x2WWm9bMVvIuKsJ96sZhcB9TJiixZjZnNkZudtIjTWr9aiQQk9q yxJlD64SMELIRY4gCbGjkv01/BKg1Sr5P0C4ZzzlDAkpjRSbzY8z5+wM7nRChgT6bY5Wkjl0W ZIj47HeUCSd5EnmCe6s06UUce2w/qy+WnyGx4CEdx74aOy94a50JjMzi4tTOruX3PSzO9n8qc gymKEhkF+q94UvlLWWAIyELp1UUtALnAUjoo0y22gu37Rn0u3la20B2yzs3ZJyqkOLMaJn7cv oxMvROZFqYSC7mdF6kdAt56pYV8WHnhUtoPFWzueoHzq0T1s0oXjUVms00h5pr1BLUA6Uiecy /cCL2FpWUdBpByxLKayXNkoguhBHqV6tfe/lZN30YE07Ec6EugHajjhRdhsB7r2FNfaBjzR7c sWMgMfrsn2W9xk28d/d2gnU5xvLiZYpv0SxMtp2nxnT26yU21EFIwz1PBpBCD7Jat9tKx/1Ny 7wSCmrnVbEMTy5OzgJGaZ3uDFbz5A1xE/N+Nqo/1ZJgv7bxCyrPWH97zGc+nzBmB+mndMQt7n uns/kAUL/RCKXATRcPX9otjKPVODA4dB9qqMLSJ77dlyklCXs2mcFKPxDzAsPYk3jFsiplUbG 2Td9RoKTW+UDEdjLvuHWdhPdBD+a9Z9ufiZHkUEL3SsIz2BGcYZJ9bvHwzwIfAU5eCTSHx1kn IAKLn/hczFUzLdabALcUtqjScw1hjZxPucfqozPyCYChZgeI2j3NMiwNN+BYiEf0y0gth7zOv 3sNLfvmxM90o45q58WL+aEHwM0BsRpPmv4zqUSYKIWmAfATJFWfHtdorcteoBqY8Me/j2TD4V RET/JlD2hRoReYPMXzjRlnD5z5p3jgEc4B4zkf5E4wBdgAB1dE51cShTqxJPwSY5uYYvcq44W qhrbEwWAD0gOef1NoALztU7C8Q0PX6ax1q8tv6OYnt/v8+5YPcQmBIfp3Y/M1rPIsUJ0WFIrt iTCcEowpasuqlk= Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 49723 Cc: phst@google.com, 49723@debbugs.gnu.org, federicotedin@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: Hi Eli, >> > +** 'expand-file-name' now checks for null bytes in filenames. >> > +The function will now check for null bytes in both NAME and >> > +DEFAULT-DIRECTORY arguments, as well as in the 'default-directory' >> > +buffer-local variable, assuming its value is used. If null bytes ar= e >> > +found, 'expand-file-name' will signal an error. >> >> Should this be implemented also in remote file names? > > Are we sure remote file names cannot include null bytes? Likely not. I have added "foo\0bar" as file name in tramp-test.el, and then I get =2D-8<---------------cut here---------------start------------->8--- Test tramp-test41-special-characters condition: (ert-test-failed ((should (file-exists-p file1)) :form (file-exists-p "/mock:gandalf:/tmp/tramp-testkLeKOx/foo\0bar") :value nil)) FAILED 1/1 tramp-test41-special-characters (0.484141 sec) =2D-8<---------------cut here---------------end--------------->8--- Well, perhaps Tramp can be improved to handle null bytes on (remote) shell level, but do we need this? Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 16 14:52:00 2021 Received: (at 49723) by debbugs.gnu.org; 16 Sep 2021 18:52:00 +0000 Received: from localhost ([127.0.0.1]:56562 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQwUK-0003KX-I0 for submit@debbugs.gnu.org; Thu, 16 Sep 2021 14:52:00 -0400 Received: from mout.gmx.net ([212.227.17.21]:55925) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQwUJ-0003KI-0C for 49723@debbugs.gnu.org; Thu, 16 Sep 2021 14:51:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1631818309; bh=n+7IgGDk4HDbjX2IpZSBwOZWs0RAEbxhyBi1o9cVA0U=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=jFeGqZ8JxIYZQ0okE1MKT2FfmSJvib9W7ETjl5ua8cbmpxlQebIL+yhuAwiU5zyKx aUSDz/Nnm5UL0OwSoE3p0SCWzmB5spWea+h+hfd72LpRDmX1tfS2oGalJVHkEW1SkA O66PmD+CmIgPWFNCEjnHrYsyA+4RM+FXLFyUqh/Y= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([213.220.158.132]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MqJqN-1nCOT13LUp-00nTxS; Thu, 16 Sep 2021 20:51:48 +0200 From: Michael Albinus To: Federico Tedin Subject: Re: bug#49723: 28.0.50; Test in coding.c for NUL bytes in filenames is not reliable References: <83o8ary5kl.fsf@gnu.org> <87pmtbj81v.fsf@gmail.com> <8335q7c655.fsf@gnu.org> <87pmta6buq.fsf@gmail.com> <837dfgaerv.fsf@gnu.org> <8735q4zcdh.fsf@gmail.com> <87tuikl79i.fsf@gmx.de> <87y27wxt6c.fsf@gmail.com> Date: Thu, 16 Sep 2021 20:51:47 +0200 In-Reply-To: <87y27wxt6c.fsf@gmail.com> (Federico Tedin's message of "Thu, 16 Sep 2021 20:38:03 +0200") Message-ID: <87ilz0l5fg.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:eNPU7XU4dqdw/KPkGMvuEkAOloUfA4BKkJiQuwqNlNuxaO1rLQD ovGqAuVyQB5wfa14hJU8mvzcRNacTMde+WIdVosh6SY92RfsFKC0o0F5jX3VI4Tg1xKgFe0 TWB5bre12dvi5R8XHMusZ9QEvhN8kIeLYmaz1udGhro0V7ZtQksn0PkLuPFqFV7Mm+keB60 UyRbWDuFYrCkTRmIQFcAQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:DBxFP7qqJOc=:S94CoRxCSllHsWwYWUKxYP z8EDPoH8mOQ0Rnde0Jt5w7VWlDbOa0XhI8q8Q37VpeiqUR1M76S8b+eS9mCLdbooceCJdXGnp BGyc28zYfIqHrNSY21o5jEbb5C2bFcuHio6ojtV9beDGNwwx5nq3cLV4n5J+B2pg5PUq2TK1o XQ/B+vu32NjexylRKecsXHnTKltgfJ9cCtq4sMANv5t0Jdt8w6eIknbAzQxZs46sUYsRVl+VX tZ+9acwzIJ/7U3vFo6hkzgq0l9De5ZBxO90pYTZoP6ZVg+JtAqv5hC1RzD2OcxtXz9FqcUVDr hYipx0AHa0YZOVCk66UQZwB5o4KWeGV0YF18+0VLBs7j3ru1/iHM2WZ+bT046OYIf+Dy3BqaD zjZ0PK9c0ik6God+qxxmDir9BrS+rTN4NylQGk3Uq5CwYKrnVUE1MsQky2OEe4iqom58AnRo2 e3Lbq6gDnFugb0vOf6/VbqP2AjlQj6smTJPNXnrHvveXK240vUNhg0EbFImhgS9aKsDuDmEsq Bo8gajaqkBEexbW2OFIbuqW6TTCGwEQzUPOjyfdRwgS4yrHgvL+CkzF84ewvN/pPrP6L69KJG IxKwIwBthNcpOLJ1WrqDUJ4DUh8VwccCVw8VYrDG/iLNw/OiwTbkn/t/TOdQdxMxV6X6HkCdf DSI9n9cCmwIpUqnNQOapy6GeeNF75eRuk4sYIa7Bf1GNuU3bJ7/mDQXkNCF14h5XqMqcn3Z5M pTtJo5rRN6BRCRY0qGfHVYZMnhnnZaGPougTn8jHYVzU9KiIqntJsowlipRxz+NSOqi1uLKvi MLjioceo1yMgYvJFs/4QX9X51xN8PG0P2hKvOAnA6JZuSQUcffw9Dog9WSixqqlKswnWXqa+n 8rNmqKKJfIoEBBrwHKR8kHgCbhOdSp/Yhm+Q4b0BpOdJ8p1+oAJB2uk9d+B2LAgkP+kRiBIMa w2j4fE+/wtC25SdeVgDqAvnAewOF5HP+0w9lmEpi4OarRQGE23/uDY7F24jZOskaZDo+O7Nxo 0fqN2+0ALthJ6MSC5G2QodKZasb3Pu/08V5vk9LrI1JTzsrlZeELD48et2UmQpbgj4epZPYt4 BEPx42aChwaEcU= X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 49723 Cc: phst@google.com, Eli Zaretskii , 49723@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Federico Tedin writes: Hi Federico, > Would this imply only doing it in `tramp-handle-expand-file-name`, or > other functions as well? > > I had thought of doing it for at least `tramp-handle-expand-file-name`, > but then I noticed that the function eventually calls `expand-file-name` > with a combination of name + dir, or only with name. So in that case I > figured that the null bytes check would be performed by > `expand-file-name` anyways. I haven't checked yet what's needed. However, there are several incarnations of `expand-file-name' implementation in Tramp, namely --8<---------------cut here---------------start------------->8--- 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) --8<---------------cut here---------------end--------------->8--- Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 16 15:08:15 2021 Received: (at 49723) by debbugs.gnu.org; 16 Sep 2021 19:08:15 +0000 Received: from localhost ([127.0.0.1]:56583 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQwk2-0003pJ-Vs for submit@debbugs.gnu.org; Thu, 16 Sep 2021 15:08:15 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43334) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQwk1-0003p5-D1 for 49723@debbugs.gnu.org; Thu, 16 Sep 2021 15:08:13 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:32848) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mQwjw-0001ZS-6u; Thu, 16 Sep 2021 15:08:08 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3139 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mQwjv-0008CD-H6; Thu, 16 Sep 2021 15:08:08 -0400 Date: Thu, 16 Sep 2021 22:07:56 +0300 Message-Id: <83tuik8hkj.fsf@gnu.org> From: Eli Zaretskii To: Michael Albinus In-Reply-To: <87pmt8l5rj.fsf@gmx.de> (message from Michael Albinus on Thu, 16 Sep 2021 20:44:32 +0200) Subject: Re: bug#49723: 28.0.50; Test in coding.c for NUL bytes in filenames is not reliable References: <83o8ary5kl.fsf@gnu.org> <87pmtbj81v.fsf@gmail.com> <8335q7c655.fsf@gnu.org> <87pmta6buq.fsf@gmail.com> <837dfgaerv.fsf@gnu.org> <8735q4zcdh.fsf@gmail.com> <87tuikl79i.fsf@gmx.de> <83v9308jb9.fsf@gnu.org> <87pmt8l5rj.fsf@gmx.de> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49723 Cc: phst@google.com, 49723@debbugs.gnu.org, federicotedin@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Michael Albinus > Cc: federicotedin@gmail.com, phst@google.com, 49723@debbugs.gnu.org > Date: Thu, 16 Sep 2021 20:44:32 +0200 > > >> Should this be implemented also in remote file names? > > > > Are we sure remote file names cannot include null bytes? > > Likely not. I have added "foo\0bar" as file name in tramp-test.el, and > then I get > > --8<---------------cut here---------------start------------->8--- > Test tramp-test41-special-characters condition: > (ert-test-failed > ((should > (file-exists-p file1)) > :form > (file-exists-p "/mock:gandalf:/tmp/tramp-testkLeKOx/foo\0bar") > :value nil)) > FAILED 1/1 tramp-test41-special-characters (0.484141 sec) > > --8<---------------cut here---------------end--------------->8--- > > Well, perhaps Tramp can be improved to handle null bytes on (remote) > shell level, but do we need this? I'm not sure. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 16 15:13:14 2021 Received: (at 49723) by debbugs.gnu.org; 16 Sep 2021 19:13:14 +0000 Received: from localhost ([127.0.0.1]:56587 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQwos-0003xs-Jj for submit@debbugs.gnu.org; Thu, 16 Sep 2021 15:13:14 -0400 Received: from mail-wr1-f54.google.com ([209.85.221.54]:40448) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQwop-0003xb-O3 for 49723@debbugs.gnu.org; Thu, 16 Sep 2021 15:13:13 -0400 Received: by mail-wr1-f54.google.com with SMTP id q26so11145201wrc.7 for <49723@debbugs.gnu.org>; Thu, 16 Sep 2021 12:13:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=dNKbItgY6fIOgdvSq1A3Plaa99cTKClO2hQb5JByy0A=; b=mJ6X7JTJBv9Q4YfqIboXNMPwT0DCotzmSO3F+5RczjQTARAaipXk+9Lu93BPWQAK56 lQkdUmHE15fl/ou3nc9p0oBhqGgpHtXrAUJ2eOCO0DjXtlgzRKEGYbC+uL3QW1oYu30T S5nvHZq0Bg9BcqoyJ75ng4q3pHGMrSswAazXoOSKRi36O04O+nziIqej5kvEF8BnC090 pm0AySTJ43bqIb3j6duEhde5VYT5+NWzVeSWTEyAdapx8blQeB9jfDNHR/b+hdfGT0Mg H28CCYwEGfOllORE/KEFLqrb+v71AqIydJ9zQD+w/s9OavnF4mVtwyeUooc1bjXcBPoN o5SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=dNKbItgY6fIOgdvSq1A3Plaa99cTKClO2hQb5JByy0A=; b=dUgeQ6eXAQdVYM6IBURgFqZcBJ10Q4QoLD2zR7hxyBhhNLM2Dgm/BUv3o2hr1E5H0i 8+9fTAKiXDu3FX8HdFfVrqxgsUGNQZm70wnwFiPgTP06wsLD/9wHAi+7IbqPkg6p4pR8 n7eSvAx4DXP2BRodvCZhDwTxQBseXZL5QsK71ER/LHmtEG+2brQtV3dkg9NRbGno7l2i U+yzk069LqB/PYgKqRHMC9IwQq7gT867XBaRXQnWBA1X3DgzUiq58VHtWGP8Z910+1RU udnyWAMw4nN7Avj5F0YvxgpYi11gckTF6mth03xZZJAprH5Nx4Udj5cXL1T25pNe7HVw jNRg== X-Gm-Message-State: AOAM533oQhUqneqTHzyuOtMJwFIto9VWtzuQie5AzlHlEdAo+rGRFhYU 2l7hu1hL7EtUyWepBf4Q8dSrSVWxfX7w8A== X-Google-Smtp-Source: ABdhPJzOntpbg/FiSSaakshoIMEJpVwaOuFHfFJTV4d97RoCSAAAJ04EWqIFZBPsJrzzwixIPlFugA== X-Received: by 2002:adf:c10b:: with SMTP id r11mr7962666wre.336.1631819585622; Thu, 16 Sep 2021 12:13:05 -0700 (PDT) Received: from gehirn (ip5b4202e5.dynamic.kabel-deutschland.de. [91.66.2.229]) by smtp.gmail.com with ESMTPSA id x13sm4355002wrg.62.2021.09.16.12.13.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Sep 2021 12:13:05 -0700 (PDT) From: Federico Tedin To: Michael Albinus Subject: Re: bug#49723: 28.0.50; Test in coding.c for NUL bytes in filenames is not reliable References: <83o8ary5kl.fsf@gnu.org> <87pmtbj81v.fsf@gmail.com> <8335q7c655.fsf@gnu.org> <87pmta6buq.fsf@gmail.com> <837dfgaerv.fsf@gnu.org> <8735q4zcdh.fsf@gmail.com> <87tuikl79i.fsf@gmx.de> <87y27wxt6c.fsf@gmail.com> <87ilz0l5fg.fsf@gmx.de> Date: Thu, 16 Sep 2021 21:13:04 +0200 In-Reply-To: <87ilz0l5fg.fsf@gmx.de> (Michael Albinus's message of "Thu, 16 Sep 2021 20:51:47 +0200") Message-ID: <87r1doxrjz.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 49723 Cc: phst@google.com, Eli Zaretskii , 49723@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Michael Albinus 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`. From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 17 03:50:38 2021 Received: (at 49723) by debbugs.gnu.org; 17 Sep 2021 07:50:38 +0000 Received: from localhost ([127.0.0.1]:58378 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mR8dq-0000yl-6C for submit@debbugs.gnu.org; Fri, 17 Sep 2021 03:50:38 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49548) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mR8do-0000yY-27 for 49723@debbugs.gnu.org; Fri, 17 Sep 2021 03:50:36 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:52676) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mR8di-0004ar-4F; Fri, 17 Sep 2021 03:50:30 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2178 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mR8dV-000169-7d; Fri, 17 Sep 2021 03:50:29 -0400 Date: Fri, 17 Sep 2021 10:49:59 +0300 Message-Id: <83fsu38wuw.fsf@gnu.org> From: Eli Zaretskii To: Federico Tedin In-Reply-To: <8735q4zcdh.fsf@gmail.com> (message from Federico Tedin on Thu, 16 Sep 2021 18:58:02 +0200) Subject: Re: bug#49723: 28.0.50; Test in coding.c for NUL bytes in filenames is not reliable References: <83o8ary5kl.fsf@gnu.org> <87pmtbj81v.fsf@gmail.com> <8335q7c655.fsf@gnu.org> <87pmta6buq.fsf@gmail.com> <837dfgaerv.fsf@gnu.org> <8735q4zcdh.fsf@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49723 Cc: phst@google.com, 49723@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Federico Tedin > Cc: phst@google.com, 49723@debbugs.gnu.org > Date: Thu, 16 Sep 2021 18:58:02 +0200 > > >> +** 'expand-file-name' now checks for null bytes in filenames. > >> +The function will now check for null bytes in both NAME and > >> +DEFAULT-DIRECTORY arguments, as well as in the 'default-directory' > >> +buffer-local variable, assuming its value is used. > > > > This should say that if null bytes are found, expand-file-name will > > signal an error. > > Makes sense! I'm attaching a revised version. Thanks. Did you run the test suite after applying the changes, and did you see no regressions? If you didn't yet run the test suite, please be sure to run all of it, as the use of expand-file-name is universal. From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 17 15:00:19 2021 Received: (at 49723) by debbugs.gnu.org; 17 Sep 2021 19:00:19 +0000 Received: from localhost ([127.0.0.1]:33014 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mRJ5v-00020R-0X for submit@debbugs.gnu.org; Fri, 17 Sep 2021 15:00:19 -0400 Received: from mail-wr1-f44.google.com ([209.85.221.44]:36541) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mRJ5s-00020D-Fu for 49723@debbugs.gnu.org; Fri, 17 Sep 2021 15:00:18 -0400 Received: by mail-wr1-f44.google.com with SMTP id g16so16723202wrb.3 for <49723@debbugs.gnu.org>; Fri, 17 Sep 2021 12:00:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=a45KkbKTFPHJph2uPdS6P/ros37nBUGa8JH8eNKofy8=; b=C6Zf23m6oLsQ9yaaSj6CgbDVTf5I7CaDANLblxSy2blLG1hkeh6Ava0bp0N8SWpNwo WCu86w9HzHm/Wi19/3s5InG2jEBJSG8CXeIUuA3m/khDyyIRO3LhG/bJ7WS3XnCl9Mrc BB4OyXpLPxpgmc81eu44z7FL5ya0lJHakQHSYlpVPKTH0osOO5QvpoG+Of5rjJa9+vyU Y0RwxIDgYMUvU3hIf9a037Uu9j8ZO1SdAaH6KJtB8C4HO3ZPzBkbIrKJX0j2MN6VfQJJ H51W0xBj4VLUAV+Jzds5JXiH9xAKiPhzQTbwLHdrLO/6STWnvlpzbRjqk06U1CF7ASvz cDpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=a45KkbKTFPHJph2uPdS6P/ros37nBUGa8JH8eNKofy8=; b=HyGCJKlH1IoMizuEntFBzN2Ntg7DgofzgBQnDmCFcoN/dQ+JpU96p2f40yNVhzZ34n JCSnscWXBWcPUIoBT2jukiS1fBCYm3fPnc4fiDCdW9F3MYXGnoOb9oUOZBxqExMHqjvT dKQLKM1+NkbYa9AeJmTLNNES/lt/KS8DjGzTcDO56C+/gJAvPdliHF+zDbfPpwmrLlxR jv7/2hgiEiJCnaqJ/XsYkz7oeU+TD0JlxUiSM9w3rgYSNpKz8ZG+L5ym26NsSCCiByP5 7UxR9MXwgBrt8v3gSUfwi5CBMTrUEq25FzXuXshpXXTQdaICXVnAnIDOx9/DkB0RXj2O WxaA== X-Gm-Message-State: AOAM531r3ItGoazzJT9gmAg/dD/6h6rRrLDg99z5+ZfqPPwXXuWrvbFH kDWq5+3FtHMhJF9A6NXC2urlxt3PYrTMiA== X-Google-Smtp-Source: ABdhPJxoUFMoiAsdpIyBuOSoD3yXCYi0iaZ4Z2DbjGckdMWOAUyQ+yhwnvmXaXM/2XoYUWdaH6E4og== X-Received: by 2002:adf:f545:: with SMTP id j5mr13919422wrp.9.1631905210252; Fri, 17 Sep 2021 12:00:10 -0700 (PDT) Received: from gehirn (ip5b4202e5.dynamic.kabel-deutschland.de. [91.66.2.229]) by smtp.gmail.com with ESMTPSA id h18sm7359145wrb.33.2021.09.17.12.00.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Sep 2021 12:00:09 -0700 (PDT) From: Federico Tedin To: Eli Zaretskii Subject: Re: bug#49723: 28.0.50; Test in coding.c for NUL bytes in filenames is not reliable References: <83o8ary5kl.fsf@gnu.org> <87pmtbj81v.fsf@gmail.com> <8335q7c655.fsf@gnu.org> <87pmta6buq.fsf@gmail.com> <837dfgaerv.fsf@gnu.org> <8735q4zcdh.fsf@gmail.com> <83fsu38wuw.fsf@gnu.org> Date: Fri, 17 Sep 2021 21:00:08 +0200 In-Reply-To: <83fsu38wuw.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 17 Sep 2021 10:49:59 +0300") Message-ID: <87czp7xc1z.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 49723 Cc: phst@google.com, 49723@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Eli Zaretskii writes: > Thanks. Did you run the test suite after applying the changes, and > did you see no regressions? If you didn't yet run the test suite, > please be sure to run all of it, as the use of expand-file-name is > universal. I hadn't, so I checked out master aa59d38c59 and applied my patch on top of it. I then ran "make check" and waited for a bit. There appears to be only two tests failing in test/lisp/time-stamp-tests.el ('time-stamp-format-day-of-week' and 'time-stamp-format-string-width'). Both seem to be unrelated to my change; maybe it's my system's strange combination of Spanish/English/German locale-related configurations (I'm attaching the log just in case). All other test files were run without problems. --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=time-stamp-tests.log Content-Description: log Running 135 tests (2021-09-17 20:46:15+0200, selector `(not (or (tag :expensive-test) (tag :unstable) (tag :nativecomp)))') passed 1/135 formatz-%-10z-hhmm (0.000985 sec) passed 2/135 formatz-%-10z-seconds (0.001173 sec) passed 3/135 formatz-%-10z-threedigit (0.000526 sec) passed 4/135 formatz-%-12z-hhmm (0.000991 sec) passed 5/135 formatz-%-12z-seconds (0.001199 sec) passed 6/135 formatz-%-12z-threedigit (0.000558 sec) passed 7/135 formatz-%-3z-hhmm (0.000924 sec) passed 8/135 formatz-%-3z-seconds (0.001093 sec) passed 9/135 formatz-%-3z-threedigit (0.000506 sec) passed 10/135 formatz-%-z-hhmm (0.000854 sec) passed 11/135 formatz-%-z-seconds (0.001047 sec) passed 12/135 formatz-%-z-threedigit (0.000491 sec) passed 13/135 formatz-%012:::z-hhmm (0.001046 sec) passed 14/135 formatz-%012:::z-seconds (0.001133 sec) passed 15/135 formatz-%012:::z-threedigit (0.000583 sec) passed 16/135 formatz-%012::z-hhmm (0.001066 sec) passed 17/135 formatz-%012::z-seconds (0.001096 sec) passed 18/135 formatz-%012::z-threedigit (0.000584 sec) passed 19/135 formatz-%012:z-hhmm (0.001047 sec) passed 20/135 formatz-%012:z-seconds (0.001066 sec) passed 21/135 formatz-%012:z-threedigit (0.000558 sec) passed 22/135 formatz-%012z-hhmm (0.001053 sec) passed 23/135 formatz-%012z-seconds (0.001166 sec) passed 24/135 formatz-%012z-threedigit (0.095949 sec) passed 25/135 formatz-%03:::z-hhmm (0.000898 sec) passed 26/135 formatz-%03:::z-seconds (0.000912 sec) passed 27/135 formatz-%03:::z-threedigit (0.000488 sec) passed 28/135 formatz-%05z-hhmm (0.000870 sec) passed 29/135 formatz-%05z-seconds (0.001055 sec) passed 30/135 formatz-%05z-threedigit (0.000480 sec) passed 31/135 formatz-%06:::z-hhmm (0.000852 sec) passed 32/135 formatz-%06:::z-seconds (0.000949 sec) passed 33/135 formatz-%06:::z-threedigit (0.000495 sec) passed 34/135 formatz-%06:z-hhmm (0.000839 sec) passed 35/135 formatz-%06:z-seconds (0.000926 sec) passed 36/135 formatz-%06:z-threedigit (0.000489 sec) passed 37/135 formatz-%06z-hhmm (0.000954 sec) passed 38/135 formatz-%06z-seconds (0.001083 sec) passed 39/135 formatz-%06z-threedigit (0.000492 sec) passed 40/135 formatz-%07:::z-hhmm (0.000957 sec) passed 41/135 formatz-%07:::z-seconds (0.001001 sec) passed 42/135 formatz-%07:::z-threedigit (0.000532 sec) passed 43/135 formatz-%07:z-hhmm (0.000938 sec) passed 44/135 formatz-%07:z-seconds (0.000979 sec) passed 45/135 formatz-%07:z-threedigit (0.000506 sec) passed 46/135 formatz-%09::z-hhmm (0.000963 sec) passed 47/135 formatz-%09::z-seconds (0.000970 sec) passed 48/135 formatz-%09::z-threedigit (0.000526 sec) passed 49/135 formatz-%0:::z-hhmm (0.000857 sec) passed 50/135 formatz-%0:::z-seconds (0.000980 sec) passed 51/135 formatz-%0:::z-threedigit (0.000534 sec) passed 52/135 formatz-%0::z-hhmm (0.000964 sec) passed 53/135 formatz-%0::z-seconds (0.001002 sec) passed 54/135 formatz-%0::z-threedigit (0.000543 sec) passed 55/135 formatz-%0:z-hhmm (0.000887 sec) passed 56/135 formatz-%0:z-seconds (0.000970 sec) passed 57/135 formatz-%0:z-threedigit (0.094870 sec) passed 58/135 formatz-%0z-hhmm (0.000828 sec) passed 59/135 formatz-%0z-seconds (0.000983 sec) passed 60/135 formatz-%0z-threedigit (0.000470 sec) passed 61/135 formatz-%10:::z-hhmm (0.001001 sec) passed 62/135 formatz-%10:::z-seconds (0.001000 sec) passed 63/135 formatz-%10:::z-threedigit (0.000493 sec) passed 64/135 formatz-%12:::z-hhmm (0.000864 sec) passed 65/135 formatz-%12:::z-seconds (0.001001 sec) passed 66/135 formatz-%12:::z-threedigit (0.000515 sec) passed 67/135 formatz-%12::z-hhmm (0.000959 sec) passed 68/135 formatz-%12::z-seconds (0.000998 sec) passed 69/135 formatz-%12::z-threedigit (0.000530 sec) passed 70/135 formatz-%12:z-hhmm (0.000921 sec) passed 71/135 formatz-%12:z-seconds (0.001011 sec) passed 72/135 formatz-%12:z-threedigit (0.000559 sec) passed 73/135 formatz-%12z-hhmm (0.000956 sec) passed 74/135 formatz-%12z-seconds (0.001112 sec) passed 75/135 formatz-%12z-threedigit (0.000514 sec) passed 76/135 formatz-%3:::z-hhmm (0.000850 sec) passed 77/135 formatz-%3:::z-seconds (0.000958 sec) passed 78/135 formatz-%3:::z-threedigit (0.000514 sec) passed 79/135 formatz-%5z-hhmm (0.000912 sec) passed 80/135 formatz-%5z-seconds (0.001076 sec) passed 81/135 formatz-%5z-threedigit (0.000507 sec) passed 82/135 formatz-%6:z-hhmm (0.000887 sec) passed 83/135 formatz-%6:z-seconds (0.000965 sec) passed 84/135 formatz-%6:z-threedigit (0.000530 sec) passed 85/135 formatz-%9::z-hhmm (0.000967 sec) passed 86/135 formatz-%9::z-seconds (0.001021 sec) passed 87/135 formatz-%9::z-threedigit (0.000549 sec) passed 88/135 formatz-%:::z-hhmm (0.096159 sec) passed 89/135 formatz-%:::z-seconds (0.000838 sec) passed 90/135 formatz-%:::z-threedigit (0.000442 sec) passed 91/135 formatz-%::z-hhmm (0.000822 sec) passed 92/135 formatz-%::z-seconds (0.000866 sec) passed 93/135 formatz-%::z-threedigit (0.000466 sec) passed 94/135 formatz-%:z-hhmm (0.000757 sec) passed 95/135 formatz-%:z-seconds (0.000848 sec) passed 96/135 formatz-%:z-threedigit (0.000466 sec) passed 97/135 formatz-%_12z-hhmm (0.001074 sec) passed 98/135 formatz-%_12z-seconds (0.001125 sec) passed 99/135 formatz-%_12z-threedigit (0.000527 sec) passed 100/135 formatz-%_7z-hhmm (0.000929 sec) passed 101/135 formatz-%_7z-seconds (0.001055 sec) passed 102/135 formatz-%_7z-threedigit (0.000501 sec) passed 103/135 formatz-%_z-hhmm (0.000903 sec) passed 104/135 formatz-%_z-seconds (0.001031 sec) passed 105/135 formatz-%_z-threedigit (0.000492 sec) passed 106/135 formatz-%z-spotcheck (0.000326 sec) passed 107/135 formatz-illegal-options (0.000445 sec) passed 108/135 time-stamp-custom-count (0.000538 sec) passed 109/135 time-stamp-custom-end (0.000311 sec) passed 110/135 time-stamp-custom-format-tabs-expand (0.000654 sec) passed 111/135 time-stamp-custom-inserts-lines (0.000468 sec) passed 112/135 time-stamp-custom-pattern (0.005087 sec) passed 113/135 time-stamp-custom-time-zone (0.000375 sec) passed 114/135 time-stamp-format-am-pm (0.000284 sec) passed 115/135 time-stamp-format-day-number-in-week (0.000231 sec) passed 116/135 time-stamp-format-day-of-month (0.000470 sec) Test time-stamp-format-day-of-week backtrace: signal(ert-test-failed (((should (equal (time-stamp-string "%3a" ref ert-fail(((should (equal (time-stamp-string "%3a" ref-time1) Mon)) : #f(compiled-function () #)() ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test ert-run-test(#s(ert-test :name time-stamp-format-day-of-week :docume ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m ert-run-tests((not (or (tag :expensive-test) (tag :unstable) (tag :n ert-run-tests-batch((not (or (tag :expensive-test) (tag :unstable) ( ert-run-tests-batch-and-exit((not (or (tag :expensive-test) (tag :un eval((ert-run-tests-batch-and-exit '(not (or (tag :expensive-test) ( command-line-1(("-L" ":." "-l" "ert" "-l" "lisp/time-stamp-tests" "- command-line() normal-top-level() Test time-stamp-format-day-of-week condition: (ert-test-failed ((should (equal (time-stamp-string "%3a" ref-time1) Mon)) :form (equal " Mo" "Mo") :value nil :explanation (arrays-of-different-length 3 2 " Mo" "Mo" first-mismatch-at 0))) FAILED 117/135 time-stamp-format-day-of-week (0.000415 sec) passed 118/135 time-stamp-format-hours-12 (0.000579 sec) passed 119/135 time-stamp-format-hours-24 (0.000581 sec) passed 120/135 time-stamp-format-ignored-modifiers (0.000306 sec) passed 121/135 time-stamp-format-minute (0.000419 sec) passed 122/135 time-stamp-format-month-name (0.000326 sec) passed 123/135 time-stamp-format-month-number (0.000418 sec) passed 124/135 time-stamp-format-multiple-conversions (0.000698 sec) passed 125/135 time-stamp-format-non-conversions (0.000174 sec) passed 126/135 time-stamp-format-non-date-conversions (0.000432 sec) passed 127/135 time-stamp-format-second (0.000424 sec) Test time-stamp-format-string-width backtrace: signal(ert-test-failed (((should (equal (time-stamp-string "%#3a" re ert-fail(((should (equal (time-stamp-string "%#3a" ref-time3) SUN)) #f(compiled-function () #)() ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test ert-run-test(#s(ert-test :name time-stamp-format-string-width :docum ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m ert-run-tests((not (or (tag :expensive-test) (tag :unstable) (tag :n ert-run-tests-batch((not (or (tag :expensive-test) (tag :unstable) ( ert-run-tests-batch-and-exit((not (or (tag :expensive-test) (tag :un eval((ert-run-tests-batch-and-exit '(not (or (tag :expensive-test) ( command-line-1(("-L" ":." "-l" "ert" "-l" "lisp/time-stamp-tests" "- command-line() normal-top-level() Test time-stamp-format-string-width condition: (ert-test-failed ((should (equal (time-stamp-string "%#3a" ref-time3) SUN)) :form (equal " SO" "SO") :value nil :explanation (arrays-of-different-length 3 2 " SO" "SO" first-mismatch-at 0))) FAILED 128/135 time-stamp-format-string-width (0.000539 sec) passed 129/135 time-stamp-format-time-zone-name (0.000231 sec) passed 130/135 time-stamp-format-time-zone-offset (0.000485 sec) passed 131/135 time-stamp-format-year-2digit (0.000393 sec) passed 132/135 time-stamp-format-year-4digit (0.000225 sec) passed 133/135 time-stamp-helper-safe-locals (0.000230 sec) passed 134/135 time-stamp-helper-string-defaults (0.000352 sec) passed 135/135 time-stamp-helper-zone-type-p (0.000208 sec) Ran 135 tests, 133 results as expected, 2 unexpected (2021-09-17 20:46:21+0200, 5.091627 sec) 2 unexpected results: FAILED time-stamp-format-day-of-week FAILED time-stamp-format-string-width --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 18 02:51:58 2021 Received: (at 49723-done) by debbugs.gnu.org; 18 Sep 2021 06:51:58 +0000 Received: from localhost ([127.0.0.1]:33411 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mRUCb-0005Nq-QZ for submit@debbugs.gnu.org; Sat, 18 Sep 2021 02:51:58 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34882) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mRUCZ-0005NX-QE for 49723-done@debbugs.gnu.org; Sat, 18 Sep 2021 02:51:56 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42028) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mRUCT-0003eU-PP; Sat, 18 Sep 2021 02:51:49 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3024 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mRUCT-00020s-BR; Sat, 18 Sep 2021 02:51:49 -0400 Date: Sat, 18 Sep 2021 09:51:33 +0300 Message-Id: <83a6ka74wa.fsf@gnu.org> From: Eli Zaretskii To: Federico Tedin In-Reply-To: <87czp7xc1z.fsf@gmail.com> (message from Federico Tedin on Fri, 17 Sep 2021 21:00:08 +0200) Subject: Re: bug#49723: 28.0.50; Test in coding.c for NUL bytes in filenames is not reliable References: <83o8ary5kl.fsf@gnu.org> <87pmtbj81v.fsf@gmail.com> <8335q7c655.fsf@gnu.org> <87pmta6buq.fsf@gmail.com> <837dfgaerv.fsf@gnu.org> <8735q4zcdh.fsf@gmail.com> <83fsu38wuw.fsf@gnu.org> <87czp7xc1z.fsf@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 49723-done Cc: phst@google.com, 49723-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Federico Tedin > Cc: phst@google.com, 49723@debbugs.gnu.org > Date: Fri, 17 Sep 2021 21:00:08 +0200 > > > Thanks. Did you run the test suite after applying the changes, and > > did you see no regressions? If you didn't yet run the test suite, > > please be sure to run all of it, as the use of expand-file-name is > > universal. > > I hadn't, so I checked out master aa59d38c59 and applied my patch on top > of it. I then ran "make check" and waited for a bit. There appears to be > only two tests failing in test/lisp/time-stamp-tests.el > ('time-stamp-format-day-of-week' and > 'time-stamp-format-string-width'). Both seem to be unrelated to my > change; maybe it's my system's strange combination of > Spanish/English/German locale-related configurations (I'm attaching the > log just in case). All other test files were run without problems. Thanks. I installed your changes, and I'm therefore closing this bug. A few minor stylistic comments, for the future . the lines in the commit log message are too wide, they should be at most 66 characters, because we produce ChangeLog files from Girt logs, and ChangeLog files have the fill-column set to 74, which includes 9-column TAB (perhaps this means the fill-column setting in .dire-locals.el should be amended?) . please quote symbols in commit log messages rather than leaving them unquoted (this doesn't apply to symbols in parentheses that state the functions which were changed) . please try to establish whether the changes need to be described in the manual(s), and mark the NEWS entries accordingly (if you decide there's a need to describe in the manual, please also include a suitable change for that) Thanks again for working on this. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 18 13:58:16 2021 Received: (at 49723-done) by debbugs.gnu.org; 18 Sep 2021 17:58:16 +0000 Received: from localhost ([127.0.0.1]:36824 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mRebP-0000xg-Or for submit@debbugs.gnu.org; Sat, 18 Sep 2021 13:58:16 -0400 Received: from mail-io1-f49.google.com ([209.85.166.49]:42850) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mRebM-0000xS-PR for 49723-done@debbugs.gnu.org; Sat, 18 Sep 2021 13:58:14 -0400 Received: by mail-io1-f49.google.com with SMTP id b10so16452302ioq.9 for <49723-done@debbugs.gnu.org>; Sat, 18 Sep 2021 10:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GLP0kJC4Wsq20IM5BXoDuZKsfGnSaG8NkqmK8fu6rZg=; b=Tib+P34spQziqBflLWUL652v5lbS+f7NxgPMoCwMflLLL5ewzIR3Q1EMZc1Amt72aE fqFUOAIYtkxT5ZpVNV46SGOVD6MPr91fe1sJMuC28EVaVgQDL3exKtX+ysvZbESdN90v tNF7PRFcfbnwVDjAgfamSGyrcYMpRDM1QcECUfrO0nx69VMNiwOgkM6zOdT5NL5f+APg D68BU/aEOG7hu0OvWFtH+5QOu6LHUf6PgzFxnF7N3d1LADF2rHqCYpcDhlVibeuGbe7E 0PBB3XpI8cp/Lejo8Ua4bDNCEuAvJEMKVL4GKcZSP3RBJZVw4zfmUc5OdGaMY0BRGbzd tfQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GLP0kJC4Wsq20IM5BXoDuZKsfGnSaG8NkqmK8fu6rZg=; b=SP1jkHjn90/JG/Fvkq7CETmfIqCINisCcnsWsp3FpZsLK+TyxJ4BCbMSe2itO6sClc jbCOnUJ6oZnt0LZNxD01ew0vPw7xz8Zqrn0oPkP5uRIFmV1x43+e9bv5zvyDAGEsuX5f KAcFWmac74mBWOc9U8fHNeq/fA6RyNGoZ2Kjcr7k3CyseDSSumudtJIiMdk1jTGmDeyc xkYWuzu05zXA3Ow0FNQW8TTsDmDn3b5SwIy2QsO0fVagAl+dkrictfTjI/558Ao3MGHd wvJyTkkVheKK3d5//kTfFQp/BNBt4WazziKpv0V7ldK7969JzThmDgALPwC8vN3GpjIf RyNw== X-Gm-Message-State: AOAM533DmjsiiqPTrF221hnSX0mc01cvDX2ziF5fPf5jB9UihqVtdZtw VVVZ8pOdAgieAs/ckQQVoMt8Qpcp0t5O9VAbr+M= X-Google-Smtp-Source: ABdhPJx4i6DqGI54XaxOoOuKqqQF/627w1jFu0pOL4rPBI1cuiY+airtLs5RBX622JnUOcTX11QRNal4RkgkPsJDth4= X-Received: by 2002:a05:6638:34a6:: with SMTP id t38mr13777583jal.19.1631987886982; Sat, 18 Sep 2021 10:58:06 -0700 (PDT) MIME-Version: 1.0 References: <83o8ary5kl.fsf@gnu.org> <87pmtbj81v.fsf@gmail.com> <8335q7c655.fsf@gnu.org> <87pmta6buq.fsf@gmail.com> <837dfgaerv.fsf@gnu.org> <8735q4zcdh.fsf@gmail.com> <83fsu38wuw.fsf@gnu.org> <87czp7xc1z.fsf@gmail.com> <83a6ka74wa.fsf@gnu.org> In-Reply-To: <83a6ka74wa.fsf@gnu.org> From: Federico Tedin Date: Sat, 18 Sep 2021 19:57:56 +0200 Message-ID: Subject: Re: bug#49723: 28.0.50; Test in coding.c for NUL bytes in filenames is not reliable To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000480a0705cc48ca81" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 49723-done Cc: phst@google.com, 49723-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000480a0705cc48ca81 Content-Type: text/plain; charset="UTF-8" Noted! Thank you. Eli Zaretskii schrieb am Sa. 18. Sept. 2021 um 08:51: > > From: Federico Tedin > > Cc: phst@google.com, 49723@debbugs.gnu.org > > Date: Fri, 17 Sep 2021 21:00:08 +0200 > > > > > Thanks. Did you run the test suite after applying the changes, and > > > did you see no regressions? If you didn't yet run the test suite, > > > please be sure to run all of it, as the use of expand-file-name is > > > universal. > > > > I hadn't, so I checked out master aa59d38c59 and applied my patch on top > > of it. I then ran "make check" and waited for a bit. There appears to be > > only two tests failing in test/lisp/time-stamp-tests.el > > ('time-stamp-format-day-of-week' and > > 'time-stamp-format-string-width'). Both seem to be unrelated to my > > change; maybe it's my system's strange combination of > > Spanish/English/German locale-related configurations (I'm attaching the > > log just in case). All other test files were run without problems. > > Thanks. I installed your changes, and I'm therefore closing this bug. > > A few minor stylistic comments, for the future > > . the lines in the commit log message are too wide, they should be at > most 66 characters, because we produce ChangeLog files from Girt > logs, and ChangeLog files have the fill-column set to 74, which > includes 9-column TAB (perhaps this means the fill-column setting > in .dire-locals.el should be amended?) > . please quote symbols in commit log messages rather than leaving > them unquoted (this doesn't apply to symbols in parentheses that > state the functions which were changed) > . please try to establish whether the changes need to be described in > the manual(s), and mark the NEWS entries accordingly (if you decide > there's a need to describe in the manual, please also include a > suitable change for that) > > Thanks again for working on this. > --000000000000480a0705cc48ca81 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Noted! Thank you.

Eli Zaretskii <eliz@gnu.org> schrieb am Sa. 18. Sept. 2021 um 08:51:=
> From: Federico Tedin <federicotedin@gmail.com><= br> > Cc: phst@google.c= om,=C2=A0 49= 723@debbugs.gnu.org
> Date: Fri, 17 Sep 2021 21:00:08 +0200
>
> > Thanks.=C2=A0 Did you run the test suite after applying the chang= es, and
> > did you see no regressions?=C2=A0 If you didn't yet run the t= est suite,
> > please be sure to run all of it, as the use of expand-file-name i= s
> > universal.
>
> I hadn't, so I checked out master aa59d38c59 and applied my patch = on top
> of it. I then ran "make check" and waited for a bit. There a= ppears to be
> only two tests failing in test/lisp/time-stamp-tests.el
> ('time-stamp-format-day-of-week' and
> 'time-stamp-format-string-width'). Both seem to be unrelated t= o my
> change; maybe it's my system's strange combination of
> Spanish/English/German locale-related configurations (I'm attachin= g the
> log just in case). All other test files were run without problems.

Thanks.=C2=A0 I installed your changes, and I'm therefore closing this = bug.

A few minor stylistic comments, for the future

=C2=A0. the lines in the commit log message are too wide, they should be at=
=C2=A0 =C2=A0most 66 characters, because we produce ChangeLog files from Gi= rt
=C2=A0 =C2=A0logs, and ChangeLog files have the fill-column set to 74, whic= h
=C2=A0 =C2=A0includes 9-column TAB (perhaps this means the fill-column sett= ing
=C2=A0 =C2=A0in .dire-locals.el should be amended?)
=C2=A0. please quote symbols in commit log messages rather than leaving
=C2=A0 =C2=A0them unquoted (this doesn't apply to symbols in parenthese= s that
=C2=A0 =C2=A0state the functions which were changed)
=C2=A0. please try to establish whether the changes need to be described in=
=C2=A0 =C2=A0the manual(s), and mark the NEWS entries accordingly (if you d= ecide
=C2=A0 =C2=A0there's a need to describe in the manual, please also incl= ude a
=C2=A0 =C2=A0suitable change for that)

Thanks again for working on this.
--000000000000480a0705cc48ca81-- From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 20 07:59:49 2021 Received: (at 49723) by debbugs.gnu.org; 20 Sep 2021 11:59:49 +0000 Received: from localhost ([127.0.0.1]:41126 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mSHxc-0003am-Qo for submit@debbugs.gnu.org; Mon, 20 Sep 2021 07:59:48 -0400 Received: from mout.gmx.net ([212.227.15.18]:59485) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mSHxc-0003aZ-1A for 49723@debbugs.gnu.org; Mon, 20 Sep 2021 07:59:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1632139178; bh=nDJYvI78Ge7SZwc3uw0YEtSMgRFSG8sT7jCbotQtQGk=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=icx66FXMOBSFO5GZA5gQt8oSAqfbmNmzRnQ57BpbPMxRowOukX+ldVOC+GZcCmXyI vqdQF1TNHrDJ39CgxquwSUyDpwrUNn18FiVRM8Allhe0qNKchXR8WtuWw8LybNQ6IL PAsziu7VrKLdhKEN6ZdIyXwQEgv+zD/5cnmdH6XE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([212.91.238.85]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MnaoZ-1nBl2y2yqj-00jYpi; Mon, 20 Sep 2021 13:59:37 +0200 From: Michael Albinus To: Federico Tedin Subject: Re: bug#49723: 28.0.50; Test in coding.c for NUL bytes in filenames is not reliable References: <83o8ary5kl.fsf@gnu.org> <87pmtbj81v.fsf@gmail.com> <8335q7c655.fsf@gnu.org> <87pmta6buq.fsf@gmail.com> <837dfgaerv.fsf@gnu.org> <8735q4zcdh.fsf@gmail.com> <87tuikl79i.fsf@gmx.de> <87y27wxt6c.fsf@gmail.com> <87ilz0l5fg.fsf@gmx.de> <87r1doxrjz.fsf@gmail.com> Date: Mon, 20 Sep 2021 13:59:36 +0200 In-Reply-To: <87r1doxrjz.fsf@gmail.com> (Federico Tedin's message of "Thu, 16 Sep 2021 21:13:04 +0200") Message-ID: <87czp3e9uf.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:SVWM0LzlVkZ1Lz2YCKr35ixqnHmpwJOJBcRrc9li510CdNsEWgT dRXWqzA/kCOkEkMKIi1ryqwO6gIz9VYlNx6r7btafECuuKZOpDu3vgNW43CtGfTvDVC+JOq y/rEm+BBMEINgRpPTzZs1h1dsRYTauIqUN+lKa6jmKjq9grkWPTmGL5Li7+HRQ27GQlQVSC YhQbROXqkr/e+jsn0qnbQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:FvbsX8o/8sw=:pLzGJifFpXtOdA9g+6a3rD 5RUUIoqizr6oPkjeZtJBTviCsjTCHUaxsb+0IGRS4LB4yScgt82NGdCjaEzKYcs1Xq0t3WAHV AmY2yBand4FP5wRF8FItvj4NFak9mQgcPkj9XneHNRmNPDio/651tA9Pu9uJiU4b825YTUEYq hX38EajF6AyaI08YnAYZUijX85DZwdzXtwlT6WQG97g5lnboBhB8D46NifRJCi5FV0dN8LihA K0PjyeCrSmo4+RYZach1+XCyRJoCPIN7EEhDCS/bdLJ1SeKrrPqkcNKdbMz2QCuQH0nBfQ81j /GvMXVvCwNvtn1B5JPzHknNhuSWHIq6v5uhjfnOx7iRJI9PJQWsetcKI8rtVP0zv6c0Ne+5Cr VJ2z9i5jy/EpVTg5tlLvrFQCBjFmolGOn32Q43z2Dwgs8xsO3Px7pvMjVzzZXYDH/cpf8IRq1 jZ+S8L2zFmqv7pPDJpaBElt+e0eu/BMO9NLTXD082PhAbexal1tXDbuyK/juPuPJnsoAjrxzQ nRZbVtbDqX7FHd9GzT4Ztuc9ayvFmq40HFBZAefxlWlJ1rmeiN6i+YdrcLYq5IObOMlLb8ZON ZYGjiuzNLffRs+GaxR1vPGrUGdDeydo6z+GWpSsqOGxMSqs2PrrNj8Fdt6k6OTeQMl0YGWO1N CYh4o8/ARlqqeS6uBopllZrvqEHeq/T9grluwDJyFOUF2JdkYOS9bRPDmTS0LIm+Ft4YXF0Vd OXjFkwIv2PDR5kFuW8AxfbE5K7MTPVrDNVe337LQ2aaWqCl+E5bYGY9j6xs4k2RGzWDA9N+Of NFxxzJr0o6tEk69X02dx9BMnAF0uZksRI80PDMoswFcsHN2BcLBke7u/xsv8MAEsXIf/kx8aW HO6quMFy9CVgMQkuwwNLx1gvqostTjixVjHZrIXr48OB+jLZqJew7VQxD1F68a4u2fRKv94qu bv/InkgrDGyqlohIf+yvZWBv6HjfC0/TsQdSp6/MpkQNTcnMZhUourTIDQ7AMNSvsw7Hs87fm GYe8B2xq7gnuMvZtNZE9W2BXYIO/DpLYgfo3o6i3/zew8s/0yVoY8hvXsCYERJmYe0N2VKgpJ rAmdS7w5yx6SEU= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 49723 Cc: phst@google.com, Eli Zaretskii , 49723@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Federico Tedin writes: Hi Federico, > 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`. Indeed. So there's no need for Tramp to do anything special. Best regards, Michael. From unknown Thu Aug 14 17:27:56 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 19 Oct 2021 11:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator