From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Newsgroups: gmane.emacs.bugs Subject: bug#40407: [PATCH] slow ENCODE_FILE and DECODE_FILE Date: Mon, 6 Apr 2020 20:13:43 +0200 Message-ID: <7A9EBE60-9CA3-4EC7-8B62-E5157A5423FB@acm.org> References: <805F9723-8298-4FD7-A47B-1E683721A5B0@acm.org> <835zegwn9y.fsf@gnu.org> <83imifv96b.fsf@gnu.org> <42EFD1AE-A96E-4613-A31E-C3723382DC6D@acm.org> <83r1x3tc6c.fsf@gnu.org> <1C9D87C7-57DD-4C61-86FE-99A7095E5085@acm.org> <83imift8fj.fsf@gnu.org> <51EFA20B-3F32-4242-82D5-EA2D2FB2FD3E@acm.org> <834ktyt5ki.fsf@gnu.org> <048BDA86-F50A-49CF-872A-2C94D1864181@acm.org> <831rp2sz8i.fsf@gnu.org> Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Content-Type: multipart/mixed; boundary="Apple-Mail=_7CB163B6-025E-42F6-9BF5-B7EAC04B41AD" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="96783"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 40407@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 06 20:37:45 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jLWcy-000P52-9i for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 06 Apr 2020 20:37:44 +0200 Original-Received: from localhost ([::1]:36958 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jLWcx-0006Yp-DD for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 06 Apr 2020 14:37:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42508) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jLWG3-0007YQ-GJ for bug-gnu-emacs@gnu.org; Mon, 06 Apr 2020 14:14:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jLWG2-0003pH-Do for bug-gnu-emacs@gnu.org; Mon, 06 Apr 2020 14:14:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37646) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jLWG2-0003or-A1 for bug-gnu-emacs@gnu.org; Mon, 06 Apr 2020 14:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jLWG2-0004kM-4l for bug-gnu-emacs@gnu.org; Mon, 06 Apr 2020 14:14:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Apr 2020 18:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40407 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 40407-submit@debbugs.gnu.org id=B40407.158619683018193 (code B ref 40407); Mon, 06 Apr 2020 18:14:02 +0000 Original-Received: (at 40407) by debbugs.gnu.org; 6 Apr 2020 18:13:50 +0000 Original-Received: from localhost ([127.0.0.1]:49192 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jLWFp-0004jN-NE for submit@debbugs.gnu.org; Mon, 06 Apr 2020 14:13:50 -0400 Original-Received: from mail205c50.megamailservers.eu ([91.136.10.215]:39162 helo=mail193c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jLWFn-0004j2-PQ for 40407@debbugs.gnu.org; Mon, 06 Apr 2020 14:13:48 -0400 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1586196825; bh=XHwEtGUucXjSocJ2hP1rjqkHzZjyUTssDu+JQ102Z3U=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=X2Y9WZiS/9vMKDRcp+WrUP+B6To62gOHvae8k89UHOe+g1hkOEwDzJI/66BRQXFfM kqBmB5OgcnbtxWewA1QF/aNWVPncm29II8JmT9bobjCd0QyYyk4bB7OEGFDvo1FUHg m52Mq+/Jp+1XzdmV0yko3rX1VYRDLSijKEHkojkU= Feedback-ID: mattiase@acm.or Original-Received: from [192.168.0.4] (c188-150-171-71.bredband.comhem.se [188.150.171.71]) (authenticated bits=0) by mail193c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 036IDhTi020096; Mon, 6 Apr 2020 18:13:45 +0000 In-Reply-To: <831rp2sz8i.fsf@gnu.org> X-Mailer: Apple Mail (2.3445.104.14) X-CTCH-RefID: str=0001.0A782F19.5E8B7159.006F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=cM2eTWWN c=1 sm=1 tr=0 a=SF+I6pRkHZhrawxbOkkvaA==:117 a=SF+I6pRkHZhrawxbOkkvaA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=M51BFTxLslgA:10 a=mDV3o1hIAAAA:8 a=rstMWfujXf1L_qdg40IA:9 a=CjuIK1q_8ugA:10 a=ND3vsFg5IG7zdj3qtFEA:9 a=B2y7HmGcmWMA:10 a=_FVE-zBwftR9WsbkzFJk:22 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:178099 Archived-At: --Apple-Mail=_7CB163B6-025E-42F6-9BF5-B7EAC04B41AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 5 apr. 2020 kl. 17.56 skrev Eli Zaretskii : > Once we do set up default-file-name-coding-system, these macros will > never return their argument (unless someone forcefully sets the > encoding to nil, in which case they deserve what they get). Do you > agree? Thank you, and yes, I do agree partly: ENCODE_FILE is the identity for = all unibyte strings no matter the coding system in use. However, my point (which I didn't do a very good job explaining) was = that if either ENCODE_FILE or DECODE_FILE are called with the assumption = that they return a new string, that is at least a latent bug. Thus I went through them all once again, and found a few questionable = calls that I'd like to fix. They rely on Fexpand_file_name returning a = new string, which may or may not be true now but we would be better = without such assumptions. (I also stumbled on a potential GC-related = bug.) Patch attached! With these fixed, nothing prevents those two functions from using = no-copy semantics. I agree this approach is better and safer than going = straight for code_convert_string_norecord in one pass. --Apple-Mail=_7CB163B6-025E-42F6-9BF5-B7EAC04B41AD Content-Disposition: attachment; filename=0001-Don-t-rely-on-copying-in-EN-DE-CODE_FILE.patch Content-Type: application/octet-stream; x-unix-mode=0644; name="0001-Don-t-rely-on-copying-in-EN-DE-CODE_FILE.patch" Content-Transfer-Encoding: quoted-printable =46rom=20ff62a3874890810823f79dac1273ebdd214ba529=20Mon=20Sep=2017=20= 00:00:00=202001=0AFrom:=20=3D?UTF-8?q?Mattias=3D20Engdeg=3DC3=3DA5rd?=3D=20= =0ADate:=20Mon,=206=20Apr=202020=2015:20:08=20+0200=0A= Subject:=20[PATCH]=20Don't=20rely=20on=20copying=20in=20{EN,DE}CODE_FILE=0A= =0ACallers=20of=20ENCODE_FILE=20and=20DECODE_FILE=20should=20not=20= assume=20that=20these=0Afunctions=20always=20return=20a=20new=20string=20= (bug#40407).=0A=0A*=20src/w32fns.c=20(Fw32_shell_execute):=0A*=20= src/w32proc.c=20(Fw32_application_type):=0ASink=20taking=20the=20address=20= of=20a=20Lisp=20string=20past=20GC=20points.=0ACopy=20values=20returned=20= from=20ENCODE_FILE=20before=20mutating=20them.=0A---=0A=20src/w32fns.c=20= =20|=204=20++--=0A=20src/w32proc.c=20|=202=20+-=0A=202=20files=20= changed,=203=20insertions(+),=203=20deletions(-)=0A=0Adiff=20--git=20= a/src/w32fns.c=20b/src/w32fns.c=0Aindex=209bb4e27b01..8d714f0b8d=20= 100644=0A---=20a/src/w32fns.c=0A+++=20b/src/w32fns.c=0A@@=20-8258,7=20= +8258,6=20@@=20parameters=20(e.g.,=20\"printto\"=20requires=20the=20= printer=20address).=20=20Otherwise,=0A=20=20=20/*=20Encode=20filename,=20= current=20directory=20and=20parameters.=20=20*/=0A=20=20=20current_dir=20= =3D=20GUI_ENCODE_FILE=20(current_dir);=0A=20=20=20document=20=3D=20= GUI_ENCODE_FILE=20(document);=0A-=20=20doc_w=20=3D=20GUI_SDATA=20= (document);=0A=20=20=20if=20(STRINGP=20(parameters))=0A=20=20=20=20=20{=0A= =20=20=20=20=20=20=20parameters=20=3D=20GUI_ENCODE_SYSTEM=20= (parameters);=0A@@=20-8269,6=20+8268,7=20@@=20parameters=20(e.g.,=20= \"printto\"=20requires=20the=20printer=20address).=20=20Otherwise,=0A=20=20= =20=20=20=20=20operation=20=3D=20GUI_ENCODE_SYSTEM=20(operation);=0A=20=20= =20=20=20=20=20ops_w=20=3D=20GUI_SDATA=20(operation);=0A=20=20=20=20=20}=0A= +=20=20doc_w=20=3D=20GUI_SDATA=20(document);=0A=20=20=20result=20=3D=20= (intptr_t)=20ShellExecuteW=20(NULL,=20ops_w,=20doc_w,=20params_w,=0A=20=09= =09=09=09=20=20=20=20=20GUI_SDATA=20(current_dir),=0A=20=09=09=09=09=20=20= =20=20=20(FIXNUMP=20(show_flag)=0A@@=20-8353,7=20+8353,7=20@@=20= parameters=20(e.g.,=20\"printto\"=20requires=20the=20printer=20address).=20= =20Otherwise,=0A=20=20=20handler=20=3D=20Ffind_file_name_handler=20= (absdoc,=20Qfile_exists_p);=0A=20=20=20if=20(NILP=20(handler))=0A=20=20=20= =20=20{=0A-=20=20=20=20=20=20Lisp_Object=20absdoc_encoded=20=3D=20= ENCODE_FILE=20(absdoc);=0A+=20=20=20=20=20=20Lisp_Object=20= absdoc_encoded=20=3D=20Fcopy_sequence=20(ENCODE_FILE=20(absdoc));=0A=20=0A= =20=20=20=20=20=20=20if=20(faccessat=20(AT_FDCWD,=20SSDATA=20= (absdoc_encoded),=20F_OK,=20AT_EACCESS)=20=3D=3D=200)=0A=20=09{=0Adiff=20= --git=20a/src/w32proc.c=20b/src/w32proc.c=0Aindex=20= de33726905..16e32e4c58=20100644=0A---=20a/src/w32proc.c=0A+++=20= b/src/w32proc.c=0A@@=20-3231,7=20+3231,7=20@@=20DEFUN=20= ("w32-application-type",=20Fw32_application_type,=0A=20=20=20char=20= *progname,=20progname_a[MAX_PATH];=0A=20=0A=20=20=20program=20=3D=20= Fexpand_file_name=20(program,=20Qnil);=0A-=20=20encoded_progname=20=3D=20= ENCODE_FILE=20(program);=0A+=20=20encoded_progname=20=3D=20= Fcopy_sequence=20(ENCODE_FILE=20(program));=0A=20=20=20progname=20=3D=20= SSDATA=20(encoded_progname);=0A=20=20=20unixtodos_filename=20(progname);=0A= =20=20=20filename_to_ansi=20(progname,=20progname_a);=0A--=20=0A2.21.1=20= (Apple=20Git-122.3)=0A=0A= --Apple-Mail=_7CB163B6-025E-42F6-9BF5-B7EAC04B41AD--