GNU bug report logs - #64697
29.0.92: cannot paste NUL on macOS (regression from Emacs 28)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 64697 in the body.
You can then email your comments to 64697 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Emacs Bug Report <bug-gnu-emacs <at> gnu.org>
Cc: Alan Third <alan <at> idiocy.org>
Subject: 29.0.92: cannot paste NUL on macOS (regression from Emacs 28)
Date: Tue, 18 Jul 2023 10:30:38 +0200

[Message part 1 (text/plain, inline)]

In Emacs 29, text pasted from the clipboard on macOS will be truncated if containing NULs.

Reproduction: copy text with NUL in the middle from Emacs 28 (or any other application), and paste into Emacs 29.

This was probably caused by 7e3c2b553f, where construction of a Lisp string was changed from make_string to build_string.

Suggested patch attached. If valid, would it qualify for emacs-29?

[lispString.diff (application/octet-stream, attachment)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: Emacs Bug Report <bug-gnu-emacs <at> gnu.org>
Subject: Re: 29.0.92: cannot paste NUL on macOS (regression from Emacs 28)
Date: Tue, 18 Jul 2023 10:22:21 +0100

On Tue, Jul 18, 2023 at 10:30:38AM +0200, Mattias Engdegård wrote:
> In Emacs 29, text pasted from the clipboard on macOS will be truncated if containing NULs.
> 
> Reproduction: copy text with NUL in the middle from Emacs 28 (or any other application), and paste into Emacs 29.
> 
> This was probably caused by 7e3c2b553f, where construction of a Lisp string was changed from make_string to build_string.

LGTM

I considered this approach but wasn't aware of any situation where
make_string would be better. You've found one. :)

> Suggested patch attached. If valid, would it qualify for emacs-29?

That's up to the maintainers, but I will say that it looks safe, if
that's a concern.

-- 
Alan Third

Message #11 received at 64697 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: alan <at> idiocy.org, 64697 <at> debbugs.gnu.org
Subject: Re: bug#64697: 29.0.92: cannot paste NUL on macOS (regression from
 Emacs 28)
Date: Tue, 18 Jul 2023 14:28:28 +0300

> Cc: Alan Third <alan <at> idiocy.org>
> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
> Date: Tue, 18 Jul 2023 10:30:38 +0200
> 
> In Emacs 29, text pasted from the clipboard on macOS will be truncated if containing NULs.
> 
> Reproduction: copy text with NUL in the middle from Emacs 28 (or any other application), and paste into Emacs 29.
> 
> This was probably caused by 7e3c2b553f, where construction of a Lisp string was changed from make_string to build_string.
> 
> Suggested patch attached. If valid, would it qualify for emacs-29?

This is OK for emacs-29, but I wonder: do we want a unibyte string
here or a multibyte string?  We should try to call either
make_unibyte_string or make_multibyte_string accordingly, because
make_string has its own ideas about which one to produce.

Thanks.

Message #14 received at 64697 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: mattias.engdegard <at> gmail.com, 64697 <at> debbugs.gnu.org
Subject: Re: bug#64697: 29.0.92: cannot paste NUL on macOS (regression from
 Emacs 28)
Date: Tue, 18 Jul 2023 14:31:37 +0300

> Cc: 64697 <at> debbugs.gnu.org
> Date: Tue, 18 Jul 2023 10:22:21 +0100
> From: Alan Third <alan <at> idiocy.org>
> 
> > This was probably caused by 7e3c2b553f, where construction of a Lisp string was changed from make_string to build_string.
> 
> I considered this approach but wasn't aware of any situation where
> make_string would be better. You've found one. :)

I would actually recommend the opposite rule of thumb: only use
build_string if you have good reasons to do so.

Basically, build_string is unreliable with anything but fixed-value
pure-ASCII strings.

Message #17 received at 64697 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: alan <at> idiocy.org, 64697 <at> debbugs.gnu.org
Subject: Re: bug#64697: 29.0.92: cannot paste NUL on macOS (regression from
 Emacs 28)
Date: Tue, 18 Jul 2023 14:00:49 +0200

18 juli 2023 kl. 13.28 skrev Eli Zaretskii <eliz <at> gnu.org>:

> do we want a unibyte string
> here or a multibyte string?
>  We should try to call either
> make_unibyte_string or make_multibyte_string accordingly, because
> make_string has its own ideas about which one to produce.

That is more than I expected to change in emacs-29, but we could do that too if you like.

Since the input is UTF-8 the result, with the patch, will always be either a multibyte string or a unibyte ASCII string. Always making a multibyte string would also do and be marginally faster, but not more correct in any meaningful way.

Message #20 received at 64697 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: alan <at> idiocy.org, 64697 <at> debbugs.gnu.org
Subject: Re: bug#64697: 29.0.92: cannot paste NUL on macOS (regression from
 Emacs 28)
Date: Tue, 18 Jul 2023 16:02:50 +0300

> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
> Date: Tue, 18 Jul 2023 14:00:49 +0200
> Cc: 64697 <at> debbugs.gnu.org,
>  alan <at> idiocy.org
> 
> 18 juli 2023 kl. 13.28 skrev Eli Zaretskii <eliz <at> gnu.org>:
> 
> > do we want a unibyte string
> > here or a multibyte string?
> >  We should try to call either
> > make_unibyte_string or make_multibyte_string accordingly, because
> > make_string has its own ideas about which one to produce.
> 
> That is more than I expected to change in emacs-29, but we could do that too if you like.

Let's install your change on emacs-29, and do the rest (if needed) on
master.

> Since the input is UTF-8 the result, with the patch, will always be either a multibyte string or a unibyte ASCII string. Always making a multibyte string would also do and be marginally faster, but not more correct in any meaningful way.

OK, but please add a comment there with the above rationale.

Thanks.

Message #23 received at 64697 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Alan Third <alan <at> idiocy.org>, 64697 <at> debbugs.gnu.org
Subject: Re: bug#64697: 29.0.92: cannot paste NUL on macOS (regression from
 Emacs 28)
Date: Tue, 18 Jul 2023 15:56:23 +0200

18 juli 2023 kl. 15.02 skrev Eli Zaretskii <eliz <at> gnu.org>:

> Let's install your change on emacs-29, and do the rest (if needed) on
> master.

Now installed on emacs-29. Any improvement will be added on master after the merge.

Alan and Eli, thank you both.

Message #28 received at 64697-done <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 64697-done <at> debbugs.gnu.org, Alan Third <alan <at> idiocy.org>
Subject: Re: bug#64697: 29.0.92: cannot paste NUL on macOS (regression from
 Emacs 28)
Date: Sat, 19 Aug 2023 19:34:07 +0200

> Now installed on emacs-29. Any improvement will be added on master after the merge.

A faster conversion was added in 722b1ebc6e. Closing.

Previous Next

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