GNU bug report logs -
#40407
[PATCH] slow ENCODE_FILE and DECODE_FILE
Previous Next
Reported by: Mattias Engdegård <mattiase <at> acm.org>
Date: Fri, 3 Apr 2020 16:11:01 UTC
Severity: normal
Tags: patch
Done: Mattias Engdegård <mattiase <at> acm.org>
Bug is archived. No further changes may be made.
Full log
Message #56 received at 40407 <at> debbugs.gnu.org (full text, mbox):
4 apr. 2020 kl. 20.25 skrev Eli Zaretskii <eliz <at> gnu.org>:
> That's true. But as a matter of fact, I don't see any calls to
> code_convert_string with NOCOPY non-zero, they all pass zero or false
> to it. So none of the existing direct calls from C wants or expects
> to get the same string.
Right. However, I did some reading and believe that nocopy=true is actually correct for all uses of {EN,DE}CODE_FILE, and in fact all calls to code_convert_string_norecord. One of the reasons is that the callers need to be careful with mutation wrt GC anyway; any post-recoding mutation is done on copies. (Not being able to change the length of strings also helps.)
I pushed what we agreed on in part for the pleasure of resolving such an old-standing bug) to master (962562cde4).
Given the limited scope of the change, would you agree to a backport of that to emacs-27?
For the reasons above, I think it's correct and proper to do (on master)
--- a/src/coding.c
+++ b/src/coding.c
@@ -9554,7 +9554,7 @@ code_convert_string (Lisp_Object string, Lisp_Object coding_system,
code_convert_string_norecord (Lisp_Object string, Lisp_Object coding_system,
bool encodep)
{
- return code_convert_string (string, coding_system, Qt, encodep, 0, 1);
+ return code_convert_string (string, coding_system, Qt, encodep, 1, 1);
}
This bug report was last modified 5 years and 93 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.