Subject: bug#40407: [PATCH] slow ENCODE_FILE and DECODE_FILE

From: Eli Zaretskii <[email-masked]>
Date: Sat, 04 Apr 2020 21:25:20 +0300

> From: Mattias Engdegård <[email-masked]>
> Date: Sat, 4 Apr 2020 20:01:12 +0200
> Cc: [email-masked]
> 
> 4 apr. 2020 kl. 19.04 skrev Eli Zaretskii <[email-masked]>:
> 
> > How so?
> 
> Because then NOCOPY suddenly matters for almost all coding systems, not just nil. After all, an all-ASCII input string and ASCII-compatible coding is not an unusual combination. This forces us to be careful when correcting the NOCOPY sense, and may expose latent bugs.

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.

> But you are right: we should trust calls to {en,de}code-coding-system with NOCOPY=t, and the rest can also remain as they are until someone cares enough to change them.

Agreed.

Btw, this bug was introduced in commit 4031e2b, 18 years ago.