GNU bug report logs - #75581
30.0.93; Crash when copy-sequence on clear-string'ed multibyte strings with text properties

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Kanakana <gudzpoz@HIDDEN>; Done: Stefan Kangas <stefankangas@HIDDEN>; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 75581 <at> debbugs.gnu.org:


Received: (at 75581) by debbugs.gnu.org; 16 Jan 2025 12:23:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 16 07:23:50 2025
Received: from localhost ([127.0.0.1]:60333 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYOuc-0007Sw-3W
	for submit <at> debbugs.gnu.org; Thu, 16 Jan 2025 07:23:50 -0500
Received: from mail-10629.protonmail.ch ([79.135.106.29]:23231)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
 id 1tYOuY-0007Sh-R8
 for 75581 <at> debbugs.gnu.org; Thu, 16 Jan 2025 07:23:47 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1737030220; x=1737289420;
 bh=b3O3CD5g5srwmR1Cg02mUk8GyOdLL5YkqYOpg6UUM0k=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post;
 b=Ux8TIMuhdJnsseO9AG1N/BvukSft7O2DhmJlnCjjwXzKTBtzExPsyWbNtFALy/BoV
 dcuhk5jQw9o8O35NQJR8XnlyF6DkOJCCQgg1ZzpQTLI5mI2E7hOpgyO5HcFODnQJ+t
 cjp3yG4yAeIEzEb76QdqW5ipNP/sDHCX4Mz0PdVBOPwUIPi564BV22lGIdZaH8NIvc
 iPPSR+MLSVFaus1i4v99lBk3CNuyU46Oxuhl6Qf23T29+zU7lxP3BxKV/2al4C54Ym
 RHn804LFSRXMW84/FVBRhffeWHgjrQefMCJ2TKvYGIIvz5e5lRIK/sO7QZWKN8Hg6A
 2gBIKoeZZkXdA==
Date: Thu, 16 Jan 2025 12:23:34 +0000
To: Eli Zaretskii <eliz@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#75581: 30.0.93;
 Crash when copy-sequence on clear-string'ed multibyte strings with
 text properties
Message-ID: <87ed13kkw6.fsf@HIDDEN>
In-Reply-To: <86y0zbgen0.fsf@HIDDEN>
References: <76c39274-df2a-4340-884f-30da2e51aecb@HIDDEN>
 <87o707275z.fsf@HIDDEN>
 <CADwFkmnN3-8NVFupMAadW58cpDR_fNgKw8nkgQhzmaxMwOFzrg@HIDDEN>
 <8734hjolxs.fsf@HIDDEN>
 <CADwFkmmdA-6svO44XtQ+x96gkMqFnSZFLddFjsbrsKgC3u9heA@HIDDEN>
 <87h65zmxqm.fsf@HIDDEN> <86ldvbi5v7.fsf@HIDDEN>
 <87v7ufknz0.fsf@HIDDEN> <86y0zbgen0.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: f0b7403760e1f1e89ac0bc5f4ee0f60f35926fdd
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 75581
Cc: 75581 <at> debbugs.gnu.org, schwab@HIDDEN, stefankangas@HIDDEN,
 gudzpoz@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

"Eli Zaretskii" <eliz@HIDDEN> writes:

>> Date: Thu, 16 Jan 2025 11:17:05 +0000
>> From: Pip Cet <pipcet@HIDDEN>
>> Cc: stefankangas@HIDDEN, 75581 <at> debbugs.gnu.org, gudzpoz@HIDDEN, sc=
hwab@HIDDEN
>>
>> "Eli Zaretskii" <eliz@HIDDEN> writes:
>>
>> > We have many SET_SOMETHING macros that modify the objects passed to
>> > them as arguments.
>>
>> The problem is treating the arguments as lvalues and turning them into
>> entirely different objects.  XSET* does that, and there are a few macros
>> that set structs, but I'm aware of only two macros that do this to Lisp
>> objects, and the other one is clearly named to indicate it coerces its
>> argument.
>>
>> So, no, not many cases like this, and this case is bad for other
>> reasons: assuming that STRING_SET_MULTIBYTE and STRING_SET_UNIBYTE
>> behave similarly seems natural to me.
>>
>> > So I see no compelling reason to make this change,
>> > which confusingly deviates from the other SET macros.
>>
>> ??? Which other *_SET_* macro assumes it is passed an lval, and turns it
>> into an object with a different identity?  Note that "STRING_SET_"
>> doesn't start with "SET" or "XSET", and that distinction is important.
>
> I said nothing about lvalues and identities.  I was talking about the

That's the point, though:

Lisp_Object string =3D string2;
STRING_SET_UNIBYTE (string);
eassert (EQ (string, string2));

will fail, sometimes.  The only other macros that behave in this way are
XSET* (which all follow this convention) and CHECK_FIXNUM_COERCE_MARKER,
which clearly indicates in its name that it coerces its argument.

> various SET* macros: the XSET* ones, SSET, STRING_SET_CHARS, ASET, and
> CHAR_TABLE_SET, to name just a few.  They all create or modify Lisp
> objects, and they all accept the objects directly, not as a pointer.

Because they don't change the value of the Lisp_Object: they only use it
as a pointer and change the underlying object.

>> > Let's leave alone this code, which worked for us for many years.
>>
>> I have no problem with reaching that decision ultimately, but the
>> premises you used to reach it aren't correct: there are no comparable
>> macros that do this, AFAIK.
>
> There are for me: I'm used to these macros from 30 years of hacking
> Emacs, and they all receive Lisp objects, not pointers to them.  So
> having one or two macros that break this pattern will be confusing,
> certainly after so many years of using the same macros as we do now.

The macro that breaks the pattern is STRING_SET_UNIBYTE.  It is
confusing.  It confused me.  "STRING_SET_UNIBYTE (string)" does not look
like it will change the value of the Lisp_Object string: it looks like
it treats the Lisp_Object as a pointer and modifies the string object it
points to.  If STRING_SET_UNIBYTE were a function rather than a macro,
it couldn't change the value of string.  STRING_SET_MULTIBYTE is a
function, and doesn't, and that's even more confusing.  If we want to
change string, the universally accepted way of doing that is to pass a
pointer to it.

>> The situation I described was:
>>
>> (setq str "a")
>> (aset str 0 #xff)
>> (aset str 0 #x100)
>
> OK, but why is this weird?  The value #x100 cannot be represented by a
> single byte, so we refuse.

If I replace the #xff by #x7f, it works.  If I replace it by #x100, it
works.  We don't refuse because #x100 requires several bytes and the
previous character didn't, we refuse because the previous character
cannot be converted to a multibyte form; however, as that character
would be overwritten anyway, why do we care?

> Looks understandable to me.

Not to me.

Pip





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75581; Package emacs. Full text available.

Message received at 75581 <at> debbugs.gnu.org:


Received: (at 75581) by debbugs.gnu.org; 16 Jan 2025 11:52:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 16 06:52:17 2025
Received: from localhost ([127.0.0.1]:60290 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYOQ5-0005vC-FD
	for submit <at> debbugs.gnu.org; Thu, 16 Jan 2025 06:52:17 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:44260)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tYOQ2-0005uy-Ia
 for 75581 <at> debbugs.gnu.org; Thu, 16 Jan 2025 06:52:15 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1tYOPw-0001Zl-4d; Thu, 16 Jan 2025 06:52:08 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=c+T6IWo5xfUHk9h/1Ixw6bwsjjcdAqH/aDWFaa7HjCs=; b=MYtEjj6/aRQ6
 G/ycM0omF2BLHZjVsNRaQ9ous0C9ZJsfF9e1VnWd6OjIZr/dO2p+20HmAPkBtoKwYGEFNbSZ/I1te
 nyigGRJoNhViZxFdj5Sw/4gZZpPsTIuSeARQJGB4SL3hIoZBUWQ+PT3HdpZz6OdmWbD0BlCYg9xGH
 BbtXFuWPAxvD+iEiy5Ur7OjVPViitwuzWju0xTZGVPP6PV1DIUUl42qAlfdu1TnOy56q7oWfr0IjT
 mqrfYfDfOl7hizEVug6cPAW25pkJe6fBHMk/mO9UCyGWJDJYeE1j5QZYlnRHdQNXM7/K2jGflnQQx
 yEh/QWaqVWWzqcWbMVsgbg==;
Date: Thu, 16 Jan 2025 13:52:03 +0200
Message-Id: <86y0zbgen0.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <87v7ufknz0.fsf@HIDDEN> (message from Pip Cet on Thu, 16
 Jan 2025 11:17:05 +0000)
Subject: Re: bug#75581: 30.0.93;
 Crash when copy-sequence on clear-string'ed multibyte strings with
 text properties
References: <76c39274-df2a-4340-884f-30da2e51aecb@HIDDEN>
 <87o707275z.fsf@HIDDEN>
 <CADwFkmnN3-8NVFupMAadW58cpDR_fNgKw8nkgQhzmaxMwOFzrg@HIDDEN>
 <8734hjolxs.fsf@HIDDEN>
 <CADwFkmmdA-6svO44XtQ+x96gkMqFnSZFLddFjsbrsKgC3u9heA@HIDDEN>
 <87h65zmxqm.fsf@HIDDEN> <86ldvbi5v7.fsf@HIDDEN>
 <87v7ufknz0.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 75581
Cc: 75581 <at> debbugs.gnu.org, schwab@HIDDEN, stefankangas@HIDDEN,
 gudzpoz@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Thu, 16 Jan 2025 11:17:05 +0000
> From: Pip Cet <pipcet@HIDDEN>
> Cc: stefankangas@HIDDEN, 75581 <at> debbugs.gnu.org, gudzpoz@HIDDEN, schwab@HIDDEN
> 
> "Eli Zaretskii" <eliz@HIDDEN> writes:
> 
> > We have many SET_SOMETHING macros that modify the objects passed to
> > them as arguments.
> 
> The problem is treating the arguments as lvalues and turning them into
> entirely different objects.  XSET* does that, and there are a few macros
> that set structs, but I'm aware of only two macros that do this to Lisp
> objects, and the other one is clearly named to indicate it coerces its
> argument.
> 
> So, no, not many cases like this, and this case is bad for other
> reasons: assuming that STRING_SET_MULTIBYTE and STRING_SET_UNIBYTE
> behave similarly seems natural to me.
> 
> > So I see no compelling reason to make this change,
> > which confusingly deviates from the other SET macros.
> 
> ??? Which other *_SET_* macro assumes it is passed an lval, and turns it
> into an object with a different identity?  Note that "STRING_SET_"
> doesn't start with "SET" or "XSET", and that distinction is important.

I said nothing about lvalues and identities.  I was talking about the
various SET* macros: the XSET* ones, SSET, STRING_SET_CHARS, ASET, and
CHAR_TABLE_SET, to name just a few.  They all create or modify Lisp
objects, and they all accept the objects directly, not as a pointer.

> > Let's leave alone this code, which worked for us for many years.
> 
> I have no problem with reaching that decision ultimately, but the
> premises you used to reach it aren't correct: there are no comparable
> macros that do this, AFAIK.

There are for me: I'm used to these macros from 30 years of hacking
Emacs, and they all receive Lisp objects, not pointers to them.  So
having one or two macros that break this pattern will be confusing,
certainly after so many years of using the same macros as we do now.

> The situation I described was:
> 
> (setq str "a")
> (aset str 0 #xff)
> (aset str 0 #x100)

OK, but why is this weird?  The value #x100 cannot be represented by a
single byte, so we refuse.  Looks understandable to me.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75581; Package emacs. Full text available.

Message received at 75581 <at> debbugs.gnu.org:


Received: (at 75581) by debbugs.gnu.org; 16 Jan 2025 11:40:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 16 06:40:31 2025
Received: from localhost ([127.0.0.1]:60254 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYOEg-0005NG-KA
	for submit <at> debbugs.gnu.org; Thu, 16 Jan 2025 06:40:31 -0500
Received: from mail-40134.protonmail.ch ([185.70.40.134]:41249)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
 id 1tYOEd-0005Mz-40
 for 75581 <at> debbugs.gnu.org; Thu, 16 Jan 2025 06:40:28 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1737027620; x=1737286820;
 bh=yyJjEp2N+sVX41loUKjKKUApHt9hx930XF7bpSiuE38=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post;
 b=nvDEKNTPFSFiI3tbtrnktFmWpKYqqjP5BhCV2AcLHJjOEEO4TgDW2atpZ/fU2yL/2
 g/Bb1pszkh908DiP1OgxQEkFscuzTreTDewvYxoOCsUd8goQhUtgUIWof8hLVamzcw
 mQF1NfE71dMvitQlizE5FvjXWXXTjftCIBLWxg7Tc7VFG5xDoKkLO8dlJQWAJdEICB
 wT6o24jUTgWbVZKGmpYDSV6kDg5U6n7exlqqwyCcTWyGNsvqpsGQfoF+u0tVuLYRTv
 QQ6cncd8E60n1DyccmFfpLVLA6W3lXomSRRbu8BUJgXOFihJo7LIIBHd1ReE32nwUZ
 S2rzwbCoyJT3Q==
Date: Thu, 16 Jan 2025 11:40:16 +0000
To: Eli Zaretskii <eliz@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#75581: 30.0.93;
 Crash when copy-sequence on clear-string'ed multibyte strings with
 text properties
Message-ID: <87r053kmwe.fsf@HIDDEN>
In-Reply-To: <86msfri6gm.fsf@HIDDEN>
References: <76c39274-df2a-4340-884f-30da2e51aecb@HIDDEN>
 <87o707275z.fsf@HIDDEN>
 <CADwFkmnN3-8NVFupMAadW58cpDR_fNgKw8nkgQhzmaxMwOFzrg@HIDDEN>
 <8734hjolxs.fsf@HIDDEN>
 <CADwFkmmdA-6svO44XtQ+x96gkMqFnSZFLddFjsbrsKgC3u9heA@HIDDEN>
 <87ldvbn0jo.fsf@HIDDEN> <86msfri6gm.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 638df09e00935e63f002beb4a43dffa7551e19fd
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75581
Cc: 75581 <at> debbugs.gnu.org, schwab@HIDDEN, stefankangas@HIDDEN,
 gudzpoz@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

"Eli Zaretskii" <eliz@HIDDEN> writes:

>> Cc: 75581 <at> debbugs.gnu.org, Kanakana <gudzpoz@HIDDEN>,
>>  Andreas Schwab <schwab@HIDDEN>
>> Date: Wed, 15 Jan 2025 23:02:32 +0000
>> From:  Pip Cet via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>>
>> The technical reason is that we simply cannot guarantee a string which
>> is entered in the minibuffer or in a real buffer won't be visible
>> somewhere: if it's in a buffer, it may be in the gap, and AFAIK there's
>> no way to clear that
>
> compact_buffer does at least part of that job, AFAICT, if it shrinks
> the gap.

I don't see how.  Worst case, it calls xrealloc which often leaves an
extra copy in memory.

> And it should be easy to add a new function that clears the
> gap completely, and expose it to Lisp or call it from clear-string.

It's easy to clear the current gap completely, but it's not what people
want, which is to actually remove the sensitive data from memory.  That
is much, much harder.

>> it's in the undo history; it's in the M-x view-lossage output.
>
> We could handle that as well, by clearing the undo-list and
> recent-keys.

So we're up to five necessary changes to do what the callers of this
function apparently assume will be achieved by it:

1. realloc must be hardened to clear the old memory
2. the gap must be cleared
3. undo history must be cleared
4. recent-keys must be cleared
5. string compaction must be hardened not to leave extra copies of
strings around

The cache line problem still remains, of course.

None of this is easy.

>> Physically, clearing memory only makes sense if
>> it's an entire cache line: a partial cache line memset will leave the
>> original copy in RAM while creating a write-back entry in the CPU cache:
>> if that is what you're worried about, the naive approach will actually
>> make things worse.
>
> I think there are APIs to clear memory securely, no?

Probably.  Even getting to the point where that matters would require
too many changes, though.

> Removing this function sounds too extreme to me, since we have that
> for many years.

You're probably right, but it should be clearly documented to prevent
only ordinary Lisp code from accessing the password, and not to do any
of the five things above.

read-passwd, for example, definitely needs more warnings than it
currently has: if I dump core after evaluating (clear-string (prog1
(read-passwd "") (garbage-collect))), I see at least three copies of the
password in the coredump.  (Possibly more that use fixnums).

Pip





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75581; Package emacs. Full text available.

Message received at 75581 <at> debbugs.gnu.org:


Received: (at 75581) by debbugs.gnu.org; 16 Jan 2025 11:17:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 16 06:17:17 2025
Received: from localhost ([127.0.0.1]:60184 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYNsD-0004Cq-6D
	for submit <at> debbugs.gnu.org; Thu, 16 Jan 2025 06:17:17 -0500
Received: from mail-4322.protonmail.ch ([185.70.43.22]:10121)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
 id 1tYNsB-0004CS-7r
 for 75581 <at> debbugs.gnu.org; Thu, 16 Jan 2025 06:17:16 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1737026228; x=1737285428;
 bh=xp3MMQYfZp93JJEge2pc4HQaqRuqzhLLKFplcxMfM3U=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post;
 b=gsbjnK0cBIekngbVkwRGqWkuABsuc8av0nvA7Gr4J8RXCyOI83LDtNA0cTFqOzli9
 SZL65oP62MY1Ip4R9BY3jf3TuD0aCHCaPTM17g6JdQvHns/p8MVlB2pSqz+G1mqYDu
 DnyeOytWctNaPkQkmBvhQgjUGNPRaQsEMdQgqJDtld80iCORFZGPX/OPTUmJagi77S
 IBiPeXrvDW6vXATXJWpmYfDoID608coF6fWEgVR+ONpNkagg566rW0KQDfK304jAvS
 mqmDMQgdDUlEjZkQ+4XDpwxhVI+H3VvOrJyArOwPcmlCuZTbRhOUdWE9yTCEe1EIgb
 HDjDi46AJnY0A==
Date: Thu, 16 Jan 2025 11:17:05 +0000
To: Eli Zaretskii <eliz@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#75581: 30.0.93;
 Crash when copy-sequence on clear-string'ed multibyte strings with
 text properties
Message-ID: <87v7ufknz0.fsf@HIDDEN>
In-Reply-To: <86ldvbi5v7.fsf@HIDDEN>
References: <76c39274-df2a-4340-884f-30da2e51aecb@HIDDEN>
 <87o707275z.fsf@HIDDEN>
 <CADwFkmnN3-8NVFupMAadW58cpDR_fNgKw8nkgQhzmaxMwOFzrg@HIDDEN>
 <8734hjolxs.fsf@HIDDEN>
 <CADwFkmmdA-6svO44XtQ+x96gkMqFnSZFLddFjsbrsKgC3u9heA@HIDDEN>
 <87h65zmxqm.fsf@HIDDEN> <86ldvbi5v7.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: bdb7eb551998c3459f50e214f7028a4fde2809c8
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.8 (-)
X-Debbugs-Envelope-To: 75581
Cc: 75581 <at> debbugs.gnu.org, schwab@HIDDEN, stefankangas@HIDDEN,
 gudzpoz@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.8 (--)

"Eli Zaretskii" <eliz@HIDDEN> writes:

>> Cc: 75581 <at> debbugs.gnu.org, Kanakana <gudzpoz@HIDDEN>,
>>  Andreas Schwab <schwab@HIDDEN>
>> Date: Thu, 16 Jan 2025 00:03:10 +0000
>> From:  Pip Cet via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>>
>> > No need, I had forgotten the strange way STRING_SET_MULTIBYTE treats i=
ts
>> > argument as an lvalue.  It's a minor issue, but I would prefer it if t=
he
>> > argument were provided as a pointer to a Lisp_Object so it's clear it
>> > can be modified.
>>
>> Patch (I've verified that the eassume-in-a-loop thing doesn't generate
>> any code with current GCC, but it'd be nice to check this for clang):
>
> We have many SET_SOMETHING macros that modify the objects passed to
> them as arguments.

The problem is treating the arguments as lvalues and turning them into
entirely different objects.  XSET* does that, and there are a few macros
that set structs, but I'm aware of only two macros that do this to Lisp
objects, and the other one is clearly named to indicate it coerces its
argument.

So, no, not many cases like this, and this case is bad for other
reasons: assuming that STRING_SET_MULTIBYTE and STRING_SET_UNIBYTE
behave similarly seems natural to me.

> So I see no compelling reason to make this change,
> which confusingly deviates from the other SET macros.

??? Which other *_SET_* macro assumes it is passed an lval, and turns it
into an object with a different identity?  Note that "STRING_SET_"
doesn't start with "SET" or "XSET", and that distinction is important.

> Let's leave alone this code, which worked for us for many years.

I have no problem with reaching that decision ultimately, but the
premises you used to reach it aren't correct: there are no comparable
macros that do this, AFAIK.

>> (I'd also like to propose that (aset str 0 x) always should work on
>> single-character strings; right now, if str contains a single unibyte
>> non-ASCII string and x is >=3D 0x100, the aset will fail, which seems
>> weird to me).

Sorry, I meant to say "non-ASCII character".

> This is a separate issue with (AFAIR) a long history.  It should be
> discussed separately.  And I don't think I understand the situation
> you describe; the below recipe doesn't signal an error (or did you
> mean a different kind of failure?):
>
>   (setq str "a")
>   (multibyte-string-p str)
>     =3D> nil
>   (aset str 0 #x100)
>     =3D> 256
>   str
>     =3D> "=C4=80"
>   (multibyte-string-p str)
>     =3D> t

The situation I described was:

(setq str "a")
(aset str 0 #xff)
(aset str 0 #x100)

Pip





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75581; Package emacs. Full text available.

Message received at 75581 <at> debbugs.gnu.org:


Received: (at 75581) by debbugs.gnu.org; 16 Jan 2025 07:18:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 16 02:18:52 2025
Received: from localhost ([127.0.0.1]:59789 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYK9U-0003az-Ae
	for submit <at> debbugs.gnu.org; Thu, 16 Jan 2025 02:18:52 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:35532)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tYK9P-0003ak-G7
 for 75581 <at> debbugs.gnu.org; Thu, 16 Jan 2025 02:18:50 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1tYK9I-00089H-EK; Thu, 16 Jan 2025 02:18:40 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
 Date; bh=XFbLwdW4eMANRYyX2GNviZZL1nPp5fVwTJsvPZr2vE8=; b=qx3zt025cR8ObhoV5mCH
 Ac+TZIcqZgZ9uRJnrtEtevcrFYBr7mxGA0eL91lCWPBi/INlJ2WqPs7NVvaK47/KGZ+Wzc3Ep53Wa
 quqKrbH3K5Tl00vwIFQK84JRaoa4wTCKgjOtL0aSbAKGKZHBTil/ECCl4NoC58oDhpSNiMpXBASqL
 X0fztozy7qiXSJLEwcw25Ctus06B29rFCn9WbWdRzgMJ5iya5hnRX0gfGBcq+yGaGou8is3w3BkKn
 NJI+LjLdFJhnspgj2NmMVUxQl6SPpGyVlYSqmncp5qDdC5iPwvvyDS4IRoFRPzdVJV6KHTtiOFiOi
 uvJ2whmpytKnyA==;
Date: Thu, 16 Jan 2025 09:18:36 +0200
Message-Id: <86ldvbi5v7.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <87h65zmxqm.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN)
Subject: Re: bug#75581: 30.0.93;
 Crash when copy-sequence on clear-string'ed multibyte strings with
 text properties
References: <76c39274-df2a-4340-884f-30da2e51aecb@HIDDEN>
 <87o707275z.fsf@HIDDEN>
 <CADwFkmnN3-8NVFupMAadW58cpDR_fNgKw8nkgQhzmaxMwOFzrg@HIDDEN>
 <8734hjolxs.fsf@HIDDEN>
 <CADwFkmmdA-6svO44XtQ+x96gkMqFnSZFLddFjsbrsKgC3u9heA@HIDDEN>
 <87h65zmxqm.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 75581
Cc: 75581 <at> debbugs.gnu.org, schwab@HIDDEN, stefankangas@HIDDEN,
 gudzpoz@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Cc: 75581 <at> debbugs.gnu.org, Kanakana <gudzpoz@HIDDEN>,
>  Andreas Schwab <schwab@HIDDEN>
> Date: Thu, 16 Jan 2025 00:03:10 +0000
> From:  Pip Cet via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
> 
> > No need, I had forgotten the strange way STRING_SET_MULTIBYTE treats its
> > argument as an lvalue.  It's a minor issue, but I would prefer it if the
> > argument were provided as a pointer to a Lisp_Object so it's clear it
> > can be modified.
> 
> Patch (I've verified that the eassume-in-a-loop thing doesn't generate
> any code with current GCC, but it'd be nice to check this for clang):

We have many SET_SOMETHING macros that modify the objects passed to
them as arguments.  So I see no compelling reason to make this change,
which confusingly deviates from the other SET macros.  Let's leave
alone this code, which worked for us for many years.

> (I'd also like to propose that (aset str 0 x) always should work on
> single-character strings; right now, if str contains a single unibyte
> non-ASCII string and x is >= 0x100, the aset will fail, which seems
> weird to me).

This is a separate issue with (AFAIR) a long history.  It should be
discussed separately.  And I don't think I understand the situation
you describe; the below recipe doesn't signal an error (or did you
mean a different kind of failure?):

  (setq str "a")
  (multibyte-string-p str)
    => nil
  (aset str 0 #x100)
    => 256
  str
    => "Ā"
  (multibyte-string-p str)
    => t





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75581; Package emacs. Full text available.

Message received at 75581 <at> debbugs.gnu.org:


Received: (at 75581) by debbugs.gnu.org; 16 Jan 2025 07:05:59 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 16 02:05:59 2025
Received: from localhost ([127.0.0.1]:59778 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYJx1-00034R-5Z
	for submit <at> debbugs.gnu.org; Thu, 16 Jan 2025 02:05:59 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:40684)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tYJwx-000347-L4
 for 75581 <at> debbugs.gnu.org; Thu, 16 Jan 2025 02:05:57 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1tYJwq-0005yZ-V1; Thu, 16 Jan 2025 02:05:49 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=X36yhEOJgZVJHqH/cs2oGNPCVLq7AWTbp2RnSx8RYNk=; b=BGtT/E45snPN
 UpEPYhyYAxJZ+dgI8ZNBDJwnDZ9l02UyxGrOraeGlVcySgBMps9XDhT7TtTtVvdsulH6XjFhtkfkg
 P8DR4FmbyvfhS3V7PlWKxkFoc83x1drrWWTIXmU5UyR6lti87JjCqla64xSErd0TtnA7MoWGeVN9H
 A2U/DcIjaW6vCHew/8qiYyawXS4SnNGa+yk3OWN5cwqOWpEfJDfQO440pu85F9h5nJUaflJIkxiFy
 6n9rfSkDK6U5j6w1ZKauZUDQWyIN4LmBgli225fA5jfq9ds9VtOy64QjPt5VT1mV57SVpp9r6Yz/s
 BFnKqcFpH9F2KMMPU9+/7g==;
Date: Thu, 16 Jan 2025 09:05:45 +0200
Message-Id: <86msfri6gm.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <87ldvbn0jo.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN)
Subject: Re: bug#75581: 30.0.93;
 Crash when copy-sequence on clear-string'ed multibyte strings with
 text properties
References: <76c39274-df2a-4340-884f-30da2e51aecb@HIDDEN>
 <87o707275z.fsf@HIDDEN>
 <CADwFkmnN3-8NVFupMAadW58cpDR_fNgKw8nkgQhzmaxMwOFzrg@HIDDEN>
 <8734hjolxs.fsf@HIDDEN>
 <CADwFkmmdA-6svO44XtQ+x96gkMqFnSZFLddFjsbrsKgC3u9heA@HIDDEN>
 <87ldvbn0jo.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 75581
Cc: 75581 <at> debbugs.gnu.org, schwab@HIDDEN, stefankangas@HIDDEN,
 gudzpoz@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Cc: 75581 <at> debbugs.gnu.org, Kanakana <gudzpoz@HIDDEN>,
>  Andreas Schwab <schwab@HIDDEN>
> Date: Wed, 15 Jan 2025 23:02:32 +0000
> From:  Pip Cet via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
> 
> The technical reason is that we simply cannot guarantee a string which
> is entered in the minibuffer or in a real buffer won't be visible
> somewhere: if it's in a buffer, it may be in the gap, and AFAIK there's
> no way to clear that

compact_buffer does at least part of that job, AFAICT, if it shrinks
the gap.  And it should be easy to add a new function that clears the
gap completely, and expose it to Lisp or call it from clear-string.

> it's in the undo history; it's in the M-x view-lossage output.

We could handle that as well, by clearing the undo-list and
recent-keys.

> Physically, clearing memory only makes sense if
> it's an entire cache line: a partial cache line memset will leave the
> original copy in RAM while creating a write-back entry in the CPU cache:
> if that is what you're worried about, the naive approach will actually
> make things worse.

I think there are APIs to clear memory securely, no?  How do other
applications do this?

In any case, we don't say in our documentation that clear-string is
secure or even intended for secure clearing of string text, so I don't
think we give someone false security promises.

Removing this function sounds too extreme to me, since we have that
for many years.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75581; Package emacs. Full text available.

Message received at 75581-done <at> debbugs.gnu.org:


Received: (at 75581-done) by debbugs.gnu.org; 16 Jan 2025 06:40:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 16 01:40:02 2025
Received: from localhost ([127.0.0.1]:59740 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYJXt-0001jA-El
	for submit <at> debbugs.gnu.org; Thu, 16 Jan 2025 01:40:01 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:34286)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tYJXq-0001im-Mq
 for 75581-done <at> debbugs.gnu.org; Thu, 16 Jan 2025 01:39:59 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1tYJXj-0000kK-AW; Thu, 16 Jan 2025 01:39:51 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=Y4M0m1FfGMYnpXTk5WmD1zNx+ix9yVIOXcavTNRbLRA=; b=sSuAVZqv5Ypv
 DlbC5KvJF1G8pr4T76T6JMRYsmfXV6nT1Y+D0u9JzqOtTUyRHH6lDu7+u7uVUW49mU7IET0mIxrni
 hLI7cwfzYyq8cBaqczRw26fDRGp5S22GWJhPuom7bFcj/nI9DU0iEaWnAdR9qJFEXWp43412AhiNK
 roYsegPrqyDaOoQEIpG9jiCy/J2KMpVTv6Ben56dOV/rLJGNnwSKKwLOF9cZa5xMp/NGdtgwgOXwX
 9dFb0EFpw1KswRvwGOLVLzWh8GYHGZLjHAlfPmn/mYs8H9MN2lcvnGs5cViArirROs1iNN1neOE+/
 /0RwDpzO8egIGlasS/CcjQ==;
Date: Thu, 16 Jan 2025 08:39:48 +0200
Message-Id: <86r053i7nv.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <CADwFkm=Rbh2WZUyS=P3Jm_5+u6R5fGCq0iq7xhN9dQwxDYJ6Kw@HIDDEN>
 (message from Stefan Kangas on Wed, 15 Jan 2025 14:19:06 -0800)
Subject: Re: bug#75581: 30.0.93; Crash when copy-sequence on clear-string'ed
 multibyte strings with text properties
References: <76c39274-df2a-4340-884f-30da2e51aecb@HIDDEN>
 <87o707275z.fsf@HIDDEN>
 <CADwFkmnN3-8NVFupMAadW58cpDR_fNgKw8nkgQhzmaxMwOFzrg@HIDDEN>
 <864j1zkdl7.fsf@HIDDEN>
 <CADwFkm=Rbh2WZUyS=P3Jm_5+u6R5fGCq0iq7xhN9dQwxDYJ6Kw@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 75581-done
Cc: gudzpoz@HIDDEN, schwab@HIDDEN, 75581-done <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Kangas <stefankangas@HIDDEN>
> Date: Wed, 15 Jan 2025 14:19:06 -0800
> Cc: schwab@HIDDEN, gudzpoz@HIDDEN, 75581-done <at> debbugs.gnu.org
> 
> > Thanks, but please also document this aspect of the function's
> > behavior in both the doc string and in the ELisp manual.
> 
> Thanks, done.  However, I pushed to master before I realized that maybe
> this belongs on emacs-30?  WDYT?

No, master is better.  This is not an urgent problem, and the code was
like that since the function was introduced 22 years ago.

Thanks.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75581; Package emacs. Full text available.

Message received at 75581 <at> debbugs.gnu.org:


Received: (at 75581) by debbugs.gnu.org; 16 Jan 2025 00:03:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 15 19:03:26 2025
Received: from localhost ([127.0.0.1]:59274 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYDM5-0007wY-LG
	for submit <at> debbugs.gnu.org; Wed, 15 Jan 2025 19:03:26 -0500
Received: from mail-4322.protonmail.ch ([185.70.43.22]:53415)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
 id 1tYDM2-0007w4-Qe
 for 75581 <at> debbugs.gnu.org; Wed, 15 Jan 2025 19:03:24 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1736985795; x=1737244995;
 bh=Gt24bOkp4IBXWLQhobplK5/gzaaraMEIBZmXspBcYxQ=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post;
 b=dg7HpIgqbslqTBU/RuG5fwTFmaPM4dCElVC/hDlZa3Ky1e2SUacJBOI6d1XMkep2F
 f7855N091UrYcOG7CX3YtxiZZkqDU50vY1AEL9gN6rtGJ2yX3okZ6+Skho9Yh6mGol
 2fl7qyKYXVo8l2lNcd0awqX9LXhblEQ2vojWVWoZxDPKQvSMnneLiPAsjmaamXKZkH
 p0z2FBFf4E4OVOpVgmQ4ODpg6b8s818Zm3bZ/qKjo3nDR1JI17BlqLouOzZu3mZXeS
 FBJhM7Q1UOll52XHfTDulkIsPX46ctB0tOsdTj5VASZhC9ERsYtx8bqPGSRuMJRyLr
 pqhq9QSVvhp+Q==
Date: Thu, 16 Jan 2025 00:03:10 +0000
To: Stefan Kangas <stefankangas@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#75581: 30.0.93;
 Crash when copy-sequence on clear-string'ed multibyte strings with
 text properties
Message-ID: <87h65zmxqm.fsf@HIDDEN>
In-Reply-To: <CADwFkmmdA-6svO44XtQ+x96gkMqFnSZFLddFjsbrsKgC3u9heA@HIDDEN>
References: <76c39274-df2a-4340-884f-30da2e51aecb@HIDDEN>
 <87o707275z.fsf@HIDDEN>
 <CADwFkmnN3-8NVFupMAadW58cpDR_fNgKw8nkgQhzmaxMwOFzrg@HIDDEN>
 <8734hjolxs.fsf@HIDDEN>
 <CADwFkmmdA-6svO44XtQ+x96gkMqFnSZFLddFjsbrsKgC3u9heA@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: c4bd7d7447e3ee639ee57b719dd992cc741483fd
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.8 (-)
X-Debbugs-Envelope-To: 75581
Cc: 75581 <at> debbugs.gnu.org, Kanakana <gudzpoz@HIDDEN>,
 Andreas Schwab <schwab@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.8 (--)

Pip Cet <pipcet@HIDDEN> writes:

> "Stefan Kangas" <stefankangas@HIDDEN> writes:
>
>> Pip Cet <pipcet@HIDDEN> writes:
>>
>>> Looks good to me.  However, on the scratch/no-purespace branch, we need
>>> to ensure that this function cannot be called on the empty multibyte
>>> string, turning it into a second empty unibyte string!  I'll push a fix
>>> to that branch in a bit.
>>
>> Please do, thanks.
>
> No need, I had forgotten the strange way STRING_SET_MULTIBYTE treats its
> argument as an lvalue.  It's a minor issue, but I would prefer it if the
> argument were provided as a pointer to a Lisp_Object so it's clear it
> can be modified.

Patch (I've verified that the eassume-in-a-loop thing doesn't generate
any code with current GCC, but it'd be nice to check this for clang):

STRING_SET_UNIBYTE (str[i++]) probably wasn't worth worrying about, but
STRING_SET_UNIBYTE (empty_multibyte_string) seemed like a plausible
mistake to me, and would have had dire results.  Anyway, changing the
API ensures we have a good look at all callers, and everything appears
to be in order (except that I think asetting a single-character string
should always work; right now, sometimes (aset str 0 #x100) will fail to
work when (progn (aset str 0 0) (aset str 0 #x100)) would work, based on
the character supposedly overwritten.  IOW, we can't implement
dead-store elimination for aset because an apparent "dead" store can
have an effect).

commit 9df159043cff1af82848e3a232c9e6cf2ecf5992 (HEAD)
Author: Pip Cet <pipcet@HIDDEN>
Date:   Wed Jan 15 23:15:19 2025 +0000

    Align STRING_SET_UNIBYTE and STRING_SET_MULTIBYTE (bug#75581)
   =20
    Calling convention is now that both identifiers refer to
    ordinary (inline) functions receiving a pointer to a Lisp_Object,
    which is modified to be the unique appropriate empty string if
    necessary.
   =20
    * src/alloc.c (make_multibyte_string): Drop 'register' hint.
    (make_string_from_bytes): Drop 'register' hint; pass a pointer to the
    Lisp_Object which might be modified.
    (make_specified_string):
    (make_clear_string):
    modified.
    * src/print.c (Fprin1_to_string):
    * src/fns.c (Fdelete):
    (Fclear_string): Pass a pointer to the Lisp_Object which might be
    * src/data.c (Faset): Also drop 'register' hint.
    * src/lisp.h (STRING_SET_UNIBYTE, STRING_SET_MULTIBYTE): Move.  Turn
    both into functions with the same calling convention.  Assert that no
    invalid multibyte string is created in 'STRING_SET_MULTIBYTE'.

diff --git a/src/alloc.c b/src/alloc.c
index 8307c74c106..1e9d3bfd69f 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -2510,7 +2510,7 @@ make_unibyte_string (const char *contents, ptrdiff_t =
length)
 make_multibyte_string (const char *contents,
 =09=09       ptrdiff_t nchars, ptrdiff_t nbytes)
 {
-  register Lisp_Object val;
+  Lisp_Object val;
   val =3D make_uninit_multibyte_string (nchars, nbytes);
   memcpy (SDATA (val), contents, nbytes);
   return val;
@@ -2524,11 +2524,11 @@ make_multibyte_string (const char *contents,
 make_string_from_bytes (const char *contents,
 =09=09=09ptrdiff_t nchars, ptrdiff_t nbytes)
 {
-  register Lisp_Object val;
+  Lisp_Object val;
   val =3D make_uninit_multibyte_string (nchars, nbytes);
   memcpy (SDATA (val), contents, nbytes);
   if (SBYTES (val) =3D=3D SCHARS (val))
-    STRING_SET_UNIBYTE (val);
+    STRING_SET_UNIBYTE (&val);
   return val;
 }
=20
@@ -2555,7 +2555,7 @@ make_specified_string (const char *contents,
   val =3D make_uninit_multibyte_string (nchars, nbytes);
   memcpy (SDATA (val), contents, nbytes);
   if (!multibyte)
-    STRING_SET_UNIBYTE (val);
+    STRING_SET_UNIBYTE (&val);
   return val;
 }
=20
@@ -2572,7 +2572,7 @@ make_clear_string (EMACS_INT length, bool clearit)
   if (!length)
     return empty_unibyte_string;
   val =3D make_clear_multibyte_string (length, length, clearit);
-  STRING_SET_UNIBYTE (val);
+  STRING_SET_UNIBYTE (&val);
   return val;
 }
=20
diff --git a/src/data.c b/src/data.c
index be85f817014..deaa8c502d4 100644
--- a/src/data.c
+++ b/src/data.c
@@ -2584,9 +2584,9 @@ DEFUN ("aset", Faset, Saset, 3, 3, 0,
        doc: /* Store into the element of ARRAY at index IDX the value NEWE=
LT.
 Return NEWELT.  ARRAY may be a vector, a string, a char-table or a
 bool-vector.  IDX starts at 0.  */)
-  (register Lisp_Object array, Lisp_Object idx, Lisp_Object newelt)
+  (Lisp_Object array, Lisp_Object idx, Lisp_Object newelt)
 {
-  register EMACS_INT idxval;
+  EMACS_INT idxval;
=20
   CHECK_FIXNUM (idx);
   idxval =3D XFIXNUM (idx);
@@ -2646,7 +2646,7 @@ DEFUN ("aset", Faset, Saset, 3, 3, 0,
 =09    if (!ASCII_CHAR_P (SREF (array, i)))
 =09      args_out_of_range (array, newelt);
 =09  /* ARRAY is an ASCII string.  Convert it to a multibyte string.  */
-=09  STRING_SET_MULTIBYTE (array);
+=09  STRING_SET_MULTIBYTE (&array);
 =09  idxval_byte =3D idxval;
 =09  p1 =3D SDATA (array) + idxval_byte;
 =09  prev_bytes =3D 1;
diff --git a/src/fns.c b/src/fns.c
index 191154c651a..edde21469cb 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -2203,7 +2203,7 @@ DEFUN ("delete", Fdelete, Sdelete, 2, 2, 0,
=20
 =09  tem =3D make_uninit_multibyte_string (nchars, nbytes);
 =09  if (!STRING_MULTIBYTE (seq))
-=09    STRING_SET_UNIBYTE (tem);
+=09    STRING_SET_UNIBYTE (&tem);
=20
 =09  for (i =3D nchars =3D nbytes =3D ibyte =3D 0;
 =09       i < SCHARS (seq);
@@ -3320,7 +3320,7 @@ DEFUN ("clear-string", Fclear_string, Sclear_string,
       CHECK_IMPURE (string, XSTRING (string));
       memset (SDATA (string), 0, len);
       STRING_SET_CHARS (string, len);
-      STRING_SET_UNIBYTE (string);
+      STRING_SET_UNIBYTE (&string);
     }
   return Qnil;
 }
diff --git a/src/lisp.h b/src/lisp.h
index a8fe2e9f6bc..31c087eda73 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -1654,25 +1654,6 @@ STRING_MULTIBYTE (Lisp_Object str)
 #define STRING_BYTES_BOUND  \
   ((ptrdiff_t) min (MOST_POSITIVE_FIXNUM, min (SIZE_MAX, PTRDIFF_MAX) - 1)=
)
=20
-/* Mark STR as a unibyte string.  */
-#define STRING_SET_UNIBYTE(STR)=09=09=09=09\
-  do {=09=09=09=09=09=09=09\
-    if (XSTRING (STR)->u.s.size =3D=3D 0)=09=09=09\
-      (STR) =3D empty_unibyte_string;=09=09=09\
-    else=09=09=09=09=09=09\
-      XSTRING (STR)->u.s.size_byte =3D -1;=09=09\
-  } while (false)
-
-/* Mark STR as a multibyte string.  Assure that STR contains only
-   ASCII characters in advance.  */
-INLINE void
-STRING_SET_MULTIBYTE (Lisp_Object str)
-{
-  /* The 0-length strings are unique&shared so we can't modify them.  */
-  eassert (XSTRING (str)->u.s.size > 0);
-  XSTRING (str)->u.s.size_byte =3D XSTRING (str)->u.s.size;
-}
-
 /* Convenience functions for dealing with Lisp strings.  */
=20
 /* WARNING: Use the 'char *' pointers to string data with care in code
@@ -4605,6 +4586,7 @@ list4i (intmax_t a, intmax_t b, intmax_t c, intmax_t =
d)
 extern Lisp_Object make_formatted_string (char *, const char *, ...)
   ATTRIBUTE_FORMAT_PRINTF (2, 3);
 extern Lisp_Object make_unibyte_string (const char *, ptrdiff_t);
+
 extern ptrdiff_t vectorlike_nbytes (const union vectorlike_header *hdr);
=20
 INLINE ptrdiff_t
@@ -5242,6 +5224,32 @@ fast_c_string_match_ignore_case (Lisp_Object regexp,
 #endif
 extern Lisp_Object decode_env_path (const char *, const char *, bool);
 extern Lisp_Object empty_unibyte_string, empty_multibyte_string;
+
+/* Mark *STRPTR as a unibyte string.  Modify *STRPTR if necessary.  */
+INLINE void
+STRING_SET_UNIBYTE (Lisp_Object *strptr)
+{
+  eassume (STRING_MULTIBYTE (*strptr));
+  if (XSTRING (*strptr)->u.s.size =3D=3D 0)
+    *strptr =3D empty_unibyte_string;
+  else
+    XSTRING (*strptr)->u.s.size_byte =3D -1;
+}
+
+/* Mark *STRPTR as a multibyte string.  Assumes that *STRPTR contains
+   only ASCII characters.  Modify *STRPTR if necessary.  */
+INLINE void
+STRING_SET_MULTIBYTE (Lisp_Object *strptr)
+{
+  eassume (!STRING_MULTIBYTE (*strptr));
+  for (ptrdiff_t i =3D 0; i < SBYTES (*strptr); i++)
+    eassume (ASCII_CHAR_P (SDATA (*strptr)[i]));
+  if (XSTRING (*strptr)->u.s.size =3D=3D 0)
+    *strptr =3D empty_multibyte_string;
+  else
+    XSTRING (*strptr)->u.s.size_byte =3D XSTRING (*strptr)->u.s.size;
+}
+
 extern AVOID terminate_due_to_signal (int, int);
 #ifdef WINDOWSNT
 extern Lisp_Object Vlibrary_cache;
diff --git a/src/print.c b/src/print.c
index f3814859cb3..62c7780416a 100644
--- a/src/print.c
+++ b/src/print.c
@@ -819,7 +819,7 @@ DEFUN ("prin1-to-string", Fprin1_to_string, Sprin1_to_s=
tring, 1, 3, 0,
   set_buffer_internal (XBUFFER (Vprin1_to_string_buffer));
   object =3D Fbuffer_string ();
   if (SBYTES (object) =3D=3D SCHARS (object))
-    STRING_SET_UNIBYTE (object);
+    STRING_SET_UNIBYTE (&object);
=20
   /* Note that this won't make prepare_to_modify_buffer call
      ask-user-about-supersession-threat because this buffer

(I'd also like to propose that (aset str 0 x) always should work on
single-character strings; right now, if str contains a single unibyte
non-ASCII string and x is >=3D 0x100, the aset will fail, which seems
weird to me).

Pip





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75581; Package emacs. Full text available.

Message received at 75581 <at> debbugs.gnu.org:


Received: (at 75581) by debbugs.gnu.org; 15 Jan 2025 23:02:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 15 18:02:47 2025
Received: from localhost ([127.0.0.1]:59205 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYCPO-00059Y-Fw
	for submit <at> debbugs.gnu.org; Wed, 15 Jan 2025 18:02:46 -0500
Received: from mail-40133.protonmail.ch ([185.70.40.133]:61597)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
 id 1tYCPL-00059F-BZ
 for 75581 <at> debbugs.gnu.org; Wed, 15 Jan 2025 18:02:44 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1736982156; x=1737241356;
 bh=lrw5qJOwFqqzmXC+TC1o40I3gOXUhQH4kEyPyXY0KmI=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post;
 b=ypSQ4hn78ojIWguidex7d1+uioUwuSUG1eX9f4FozOyk9unEhHkseGxUM0/CrBmlk
 LoTK9U0FnOvlY69T6jcWkPfjX9VbSpiOWZ7rlwguNkDBPoFYM8ClSf4QafcCCUybVK
 HhE+OztBTO5CsMsIoLV2DF+db7/wMpuLlmqNSY7IYmkrBVSegEvRItPE+jxV0PMLpr
 6Z1Ww3jej6BRKe9K8z+2ZFM/Z6KY9d8YABxZt2vxyKiTL0ExlgMNb9gxydXKdCERoD
 eUxiSouUDROV/URLX7BkFuwiZaGAtifmURLO3q0KIE3rR7znmL2sUCbQj5PkXq4yW1
 b59oCo1fwgkmg==
Date: Wed, 15 Jan 2025 23:02:32 +0000
To: Stefan Kangas <stefankangas@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#75581: 30.0.93;
 Crash when copy-sequence on clear-string'ed multibyte strings with
 text properties
Message-ID: <87ldvbn0jo.fsf@HIDDEN>
In-Reply-To: <CADwFkmmdA-6svO44XtQ+x96gkMqFnSZFLddFjsbrsKgC3u9heA@HIDDEN>
References: <76c39274-df2a-4340-884f-30da2e51aecb@HIDDEN>
 <87o707275z.fsf@HIDDEN>
 <CADwFkmnN3-8NVFupMAadW58cpDR_fNgKw8nkgQhzmaxMwOFzrg@HIDDEN>
 <8734hjolxs.fsf@HIDDEN>
 <CADwFkmmdA-6svO44XtQ+x96gkMqFnSZFLddFjsbrsKgC3u9heA@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 4f72a0c51382f0ed574e2b5485b7c9873b674ca4
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75581
Cc: 75581 <at> debbugs.gnu.org, Kanakana <gudzpoz@HIDDEN>,
 Andreas Schwab <schwab@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

"Stefan Kangas" <stefankangas@HIDDEN> writes:

> Pip Cet <pipcet@HIDDEN> writes:
>
>> Looks good to me.  However, on the scratch/no-purespace branch, we need
>> to ensure that this function cannot be called on the empty multibyte
>> string, turning it into a second empty unibyte string!  I'll push a fix
>> to that branch in a bit.
>
> Please do, thanks.

No need, I had forgotten the strange way STRING_SET_MULTIBYTE treats its
argument as an lvalue.  It's a minor issue, but I would prefer it if the
argument were provided as a pointer to a Lisp_Object so it's clear it
can be modified.

>> However, if this function is meant to clear a string from memory
>> to prevent leaving confidential data in memory, that won't work with
>> MPS.  (I suppose it's reasonably clear that no protection whatsoever
>> applies to string properties?)
>>
>> The problem is MPS allocates string data in a "copying" pool, so several
>> copies of the string will usually be present.
>>
>> alloc.c string compaction may also result in recently-used short strings
>> remaining in memory, IIUC, but only if an alloc.c GC cycle happens
>> between string creation and the clear-string call.  (But if it does
>> happen, it's very likely that a copy of the string is created!)
>>
>> How important is this feature?  What we have now is better that nothing,
>> but if people start relying on it in any way, that's worse than nothing.
>> A stern warning in the docstring may help reduce the problem.
>
> I think a stern warning in the docstring makes sense.  This is
> potentially security-critical, and we should better make sure that we
> can make no guarantees here.

I'm worried that providing a "security" feature like this one may raise
false expectations that Emacs provides similar "security" features
(usually, in this context, "security" very quickly becomes code for
"ensure that sensitive data is only ever exposed to
manufacturer-provided proprietary software") in other contexts, and I
really don't think we want to do that.

The technical reason is that we simply cannot guarantee a string which
is entered in the minibuffer or in a real buffer won't be visible
somewhere: if it's in a buffer, it may be in the gap, and AFAIK there's
no way to clear that; it's in the undo history; it's in the M-x
view-lossage output.  Physically, clearing memory only makes sense if
it's an entire cache line: a partial cache line memset will leave the
original copy in RAM while creating a write-back entry in the CPU cache:
if that is what you're worried about, the naive approach will actually
make things worse.

The philosophical reason is that it seems harmless to offer an optional
additional security feature with no promises, but we've seen these
"evolve" into requirements which are being abused to harm Free Software,
in particular, in too many cases.  Software signing used to be optional
with all promises made it would be used only to improve security, not to
lock out Free Software, but now many people cannot run Emacs on their
locked-down employer-provided devices, and I fear it's only a matter of
time before that is expanded to most Android phones.

> It would be nice if we could have a guaranteed secure way of allocating
> and deallocating strings for passwords from ELisp.  Could something like
> that be done?  I can think of several dumb and hacky ways to do it, but
> none that are clean or smart.

We could expose pin_string: pinned strings aren't compacted, so clearing
them is safer if the old GC is in use.

But it's not clear to me what this is supposed to protect against.  If
it's physical memory inspection, we need to know a lot about the CPU for
our operation to make sense; pinning a short string and memsetting it
will virtually ensure that the previous contents will remain in RAM for
longer than they would if the string had been garbage-collected and
overwritten.

If it's disk storage, we need to look into madvise(2), mlock(2),
mlock2(), and memfd_secret(2), at least on GNU/Linux (in the case of
memfd_secret, I'm tempted to omit the "GNU/": it seems to me that this
is a Linux kernel attempt to obey security protocols which ultimately
lead to "Trusted Computing", and the GNU position on that is clear).

This isn't a simple matter, and it may be best to remove clear-string
entirely.

Pip





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75581; Package emacs. Full text available.

Message received at 75581 <at> debbugs.gnu.org:


Received: (at 75581) by debbugs.gnu.org; 15 Jan 2025 22:21:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 15 17:21:32 2025
Received: from localhost ([127.0.0.1]:59121 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYBlU-0003CH-1Z
	for submit <at> debbugs.gnu.org; Wed, 15 Jan 2025 17:21:32 -0500
Received: from mail-ed1-x533.google.com ([2a00:1450:4864:20::533]:45086)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>)
 id 1tYBlR-0003C3-8O
 for 75581 <at> debbugs.gnu.org; Wed, 15 Jan 2025 17:21:30 -0500
Received: by mail-ed1-x533.google.com with SMTP id
 4fb4d7f45d1cf-5d9f0a6ad83so456419a12.2
 for <75581 <at> debbugs.gnu.org>; Wed, 15 Jan 2025 14:21:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1736979683; x=1737584483; darn=debbugs.gnu.org;
 h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
 :from:from:to:cc:subject:date:message-id:reply-to;
 bh=cS/Y0O0GAx+VGtVCcybcc5HOaKUKJNKhG69dj4clzrw=;
 b=QewaL5TqUWOpWjTZnB0QR1ZUYR6YuO3VPrRZ9vcPoD7cktOJ8Wo6kAjfVG/rO8xSIz
 Z2JOlYJYwMpNpWAiGYvYOXS6cNoZqds+gt41I+P1zR8aJlx1Ok87vYOY7G/SK/j1b8Gk
 EXsR0FCJVgazhWgtIF7VRBHoHdHlfVm/Cwn3Sf74wGuOInmCR9PTSrmmfExD80WyKwzm
 CbvXFUsS5c/0UZDsaxCjMWv7eJ6hfpQApjKwHxTr9ilBxXb9mQRBDtpZq15LchV8UKsH
 /FAReMbKYQSz5O0REI1d7/jX+jX7EsOmYlHnJyj9hYlpCQoq5eKNaruI4hO4LcQ9acmZ
 KQ+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1736979683; x=1737584483;
 h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
 :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=cS/Y0O0GAx+VGtVCcybcc5HOaKUKJNKhG69dj4clzrw=;
 b=InfvzLFpJS5LSGPe1l2r38e5L29r7JqmqPEo5a8RwxrBnXqvk8nF317MWOtCzfS5N6
 dRyg9sZOt3Hq2fLsPTNnDmu54JAJ3wLy+3/oMk8CXWNVFxzGX+rishSBuCrLNkFOpf/7
 /3q0KsTB3xaagLnDmbHAoSgjNbfui7naX5ApoNAwwRHqy5XlV79nPPagvD3QJOfvgQ8s
 nbFNS2JqHgVfAJaw3A7+4hyonKZB/9815bDcRFS3Peiq5p1oWg2pi/zUJQcAZc5Lr1aC
 D6jd8l80OhADn+RY7PvTFBdrUbRRfhq5Bp1E81gPm2m3pEfGi5RqM92XVx1ltuB35HqM
 ZGqg==
X-Forwarded-Encrypted: i=1;
 AJvYcCWHYO7fdi68Mra9lPif/brPiPM6UNLlN6i5uKhN+KD31lYQPFVEcfrfOe+ZAC+wBEzmzbMxrg==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yy6ZxfcXLaizVBHDd69B/2nAHrO02FdiWugmSeH39u2g5BLs9Wp
 tCUrt/G76izD4IvlAlwaCWxJaQSKe6b4rZ6X2Uy4nC06QjPgYdZSoH1xqUhbt1quhonrFnj5GWt
 Sr+Ju1RleFEYRmmew361UyA4JArA=
X-Gm-Gg: ASbGnctM1MxMum1BN5TbCKfTt4j4HjhwosKHlDKJM3hhAytp/aBmL4CuWVVEd1ouEIt
 Y7Q9jY/G+7b1NoENBA1iadlQ740yUudEN7eAtin2y
X-Google-Smtp-Source: AGHT+IG4JE3+VYKc9/Hs+IQm8OL+r3OuzhRuk1xS9euCQArKLf/Cayf88lHVtiG4SdI5qztg3IRJHRCzW04b9975FHw=
X-Received: by 2002:a05:6402:5254:b0:5d2:719c:8bf3 with SMTP id
 4fb4d7f45d1cf-5d972e0a6e2mr29323945a12.9.1736979682978; Wed, 15 Jan 2025
 14:21:22 -0800 (PST)
Received: from 753933720722 named unknown by gmailapi.google.com with
 HTTPREST; Wed, 15 Jan 2025 17:21:22 -0500
From: Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <87y0zbn6n7.fsf@HIDDEN>
References: <76c39274-df2a-4340-884f-30da2e51aecb@HIDDEN>
 <87o707275z.fsf@HIDDEN>
 <CADwFkmnN3-8NVFupMAadW58cpDR_fNgKw8nkgQhzmaxMwOFzrg@HIDDEN>
 <87y0zbn6n7.fsf@HIDDEN>
MIME-Version: 1.0
Date: Wed, 15 Jan 2025 17:21:22 -0500
X-Gm-Features: AbW1kvaNP1ZNPW1OCugURopZm6vXJm3ze46uzU84Dwq7DUAMUwkOBqfmMEOOarM
Message-ID: <CADwFkm=0o1bUbESN=Hrfq3Eo2+LMD1SHVNY6OVQLRZBz_MTL7w@HIDDEN>
Subject: Re: bug#75581: 30.0.93; Crash when copy-sequence on clear-string'ed
 multibyte strings with text properties
To: Pip Cet <pipcet@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75581
Cc: 75581 <at> debbugs.gnu.org, Kanakana <gudzpoz@HIDDEN>,
 Andreas Schwab <schwab@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Pip Cet <pipcet@HIDDEN> writes:

> Sorry, false alarm.  STRING_SET_UNIBYTE modifies its argument in this
> case, replacing it by the appropriate empty string (which is unused).
>
> The only difference is that (clear-string "") no longer throws an error,
> but I don't see a problem with either behavior in that case.

Thanks for checking that.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75581; Package emacs. Full text available.

Message received at 75581-done <at> debbugs.gnu.org:


Received: (at 75581-done) by debbugs.gnu.org; 15 Jan 2025 22:19:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 15 17:19:15 2025
Received: from localhost ([127.0.0.1]:59101 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYBjH-00031B-AR
	for submit <at> debbugs.gnu.org; Wed, 15 Jan 2025 17:19:15 -0500
Received: from mail-ed1-x52e.google.com ([2a00:1450:4864:20::52e]:49410)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>)
 id 1tYBjE-00030v-MR
 for 75581-done <at> debbugs.gnu.org; Wed, 15 Jan 2025 17:19:14 -0500
Received: by mail-ed1-x52e.google.com with SMTP id
 4fb4d7f45d1cf-5da135d3162so394552a12.3
 for <75581-done <at> debbugs.gnu.org>; Wed, 15 Jan 2025 14:19:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1736979546; x=1737584346; darn=debbugs.gnu.org;
 h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
 :from:from:to:cc:subject:date:message-id:reply-to;
 bh=JnYO31+zy7ciLJAMXXpE6cJrtzLVsJ/zE6QBBH6hPHA=;
 b=YgPEPpNlcVLsZiTnsXG0Bd+Qw2jgo47G86xomOhcq9RCdlhjnn1xxIsfDQJXe3woYI
 sYV4OoQg2uLgmHJ/lmG87UN6JEvPxcmzqCKLnjw6MXutqD19bdXtW3otEHre7dJALvbs
 DfGzu3W11FqE0PIMwXSm+rUkIxcrAZL9vxJp2xx/MHPA+Tcwf+mZWPlkky3JXFwy2LWj
 /b5w2z1rKU64uHFUI7T8OnK4duHK7z2CCMjG+7NRb1V8HLn6ARxNizW/qrcSvwjvmgzX
 j/83bg7YE6DTtOiPj4dIBHBC0gc8ruYs4XdKs7gU3qkcf9oS0FPlKY/TqNn9sug5IUfj
 QMcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1736979546; x=1737584346;
 h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
 :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=JnYO31+zy7ciLJAMXXpE6cJrtzLVsJ/zE6QBBH6hPHA=;
 b=ch5RiBwG7LpYHxFSOOUZy47gAZvoUd4Jd8VxfAy84TLLY46Mn7xt1+hnFua+EjZD7G
 e3xdQNHh7HJbyH4DpxxIKxWQg4gqwM0FsWydr/pLecoF0bavRIyOdZHgBxrlCH3uzM5w
 4sZKrwH1Dge/hY3NSwUCca8c1PH2THAPWUeTMWGbp5GyF2Y7ebF3GxzyRx/hCvbRujZl
 KYxcnuaoJX2y7sawcq0wimrcBqzi5USPxWkkLxYr9wTxdjExcxzGUeW08bInCqu/pqS9
 aIqYT8pIiZN7xuhXCn/s4qDNTmyIRrVCcd2gR0IlsdK+GDV4lUN6o82vrlCwpwwl6cC6
 F7Tw==
X-Forwarded-Encrypted: i=1;
 AJvYcCWNulsOKzyVasfzEFfICvjpEozgSuTvKcVpWQsqEWRNbpf+mYS+1AJPIhhLI1fo7hT2dhqvhuYa/NM8 <at> debbugs.gnu.org
X-Gm-Message-State: AOJu0YxSmAaGW+o0obvv5Gkl3VqoIz6EahEr5aOby/8FUpUux9JjLSI3
 6q3tdc5KfGSBygHIMLiKaBsxKxPZY/7xTtVZg4Qw1BtgH21Ms9rDl7axe8Yx78UFvzNuXGUCk0d
 Z5BrlYbQcWsRDasL6hlHl4uwlIH8=
X-Gm-Gg: ASbGncswBXkfr/fDvxS7n+Zh44XLFpJYUZcKlPcF/p94C2T5R5lwF9KJluTEzBxoqJV
 zai2HaeORwQZLpcXPMniz5kuykNnw1wSXpmlKSNT4
X-Google-Smtp-Source: AGHT+IHIbJ1cYYx+Zpw9PPK107b8t2X3TW0rklwJp5IM8dWmLoE2F7zz5fKN4H7QhIV3bJTKpVBwLoAsg88ipr/wm30=
X-Received: by 2002:a05:6402:5205:b0:5d2:7199:ae6 with SMTP id
 4fb4d7f45d1cf-5d972e04bbemr28540137a12.9.1736979546495; Wed, 15 Jan 2025
 14:19:06 -0800 (PST)
Received: from 753933720722 named unknown by gmailapi.google.com with
 HTTPREST; Wed, 15 Jan 2025 14:19:06 -0800
From: Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <864j1zkdl7.fsf@HIDDEN>
References: <76c39274-df2a-4340-884f-30da2e51aecb@HIDDEN>
 <87o707275z.fsf@HIDDEN>
 <CADwFkmnN3-8NVFupMAadW58cpDR_fNgKw8nkgQhzmaxMwOFzrg@HIDDEN>
 <864j1zkdl7.fsf@HIDDEN>
MIME-Version: 1.0
Date: Wed, 15 Jan 2025 14:19:06 -0800
X-Gm-Features: AbW1kvZy6Cxxbil3VcTHUjbsjoiPdMpEiSNGz80EWJdrhx9BoyfK8kUjznlEBVg
Message-ID: <CADwFkm=Rbh2WZUyS=P3Jm_5+u6R5fGCq0iq7xhN9dQwxDYJ6Kw@HIDDEN>
Subject: Re: bug#75581: 30.0.93; Crash when copy-sequence on clear-string'ed
 multibyte strings with text properties
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75581-done
Cc: gudzpoz@HIDDEN, schwab@HIDDEN, 75581-done <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Version: 31.1

Eli Zaretskii <eliz@HIDDEN> writes:

>> Cc: 75581 <at> debbugs.gnu.org
>> From: Stefan Kangas <stefankangas@HIDDEN>
>> Date: Wed, 15 Jan 2025 15:15:06 -0500
>>
>> Andreas Schwab <schwab@HIDDEN> writes:
>>
>> > On Jan 15 2025, Kanakana wrote:
>> >
>> >> I don't know. Are text properties expected to handle string length
>> >> change via clear-string?
>> >
>> > clear-string should probably remove any text properties.
>>
>> Agreed.  This patch fixes the crash for me:
>>
>> diff --git a/src/fns.c b/src/fns.c
>> index 191154c651a..c48cdf879e4 100644
>> --- a/src/fns.c
>> +++ b/src/fns.c
>> @@ -3315,6 +3315,8 @@ DEFUN ("clear-string", Fclear_string, Sclear_string,
>>  {
>>    CHECK_STRING (string);
>>    ptrdiff_t len = SBYTES (string);
>> +  Fset_text_properties (make_fixnum (0), make_fixnum (SCHARS (string)),
>> +			Qnil, string);
>>    if (len != 0 || STRING_MULTIBYTE (string))
>>      {
>>        CHECK_IMPURE (string, XSTRING (string));
>
> Thanks, but please also document this aspect of the function's
> behavior in both the doc string and in the ELisp manual.

Thanks, done.  However, I pushed to master before I realized that maybe
this belongs on emacs-30?  WDYT?




Notification sent to Kanakana <gudzpoz@HIDDEN>:
bug acknowledged by developer. Full text available.
Reply sent to Stefan Kangas <stefankangas@HIDDEN>:
You have taken responsibility. Full text available.

Message received at 75581 <at> debbugs.gnu.org:


Received: (at 75581) by debbugs.gnu.org; 15 Jan 2025 22:02:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 15 17:02:36 2025
Received: from localhost ([127.0.0.1]:59046 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYBTA-0002F3-2e
	for submit <at> debbugs.gnu.org; Wed, 15 Jan 2025 17:02:36 -0500
Received: from mail-ed1-x532.google.com ([2a00:1450:4864:20::532]:45073)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>)
 id 1tYBT8-0002Eq-4F
 for 75581 <at> debbugs.gnu.org; Wed, 15 Jan 2025 17:02:35 -0500
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5d9f0a6ad83so424012a12.2
 for <75581 <at> debbugs.gnu.org>; Wed, 15 Jan 2025 14:02:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1736978547; x=1737583347; darn=debbugs.gnu.org;
 h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
 :from:from:to:cc:subject:date:message-id:reply-to;
 bh=gT+O2+nkIG0eMoEF25SGVyBBAKSWpQNQwaIvh3Sy8Mg=;
 b=W64iCOxD055jbHHoKsrLyqHzZDFGwuk70Yw+fPAA+SxaM3hN9XYKdpJIDrJPg6Dm4c
 /e7cFJQ975rbYqijfxtX6V2k5iX791D+1e/o8UwjpS7f9P3Z4FKZtwv72AQcsp+Tv1L6
 RxRacDPozroyT9nysHPhYdpT3s0ULRK0WtSqa/fB7eMVrwmd5LNBobu43S4BE2piLGOi
 oVFcxxI729IwOMABCpvmdbKx68xlFhtlglMzJo8JuZPxIFxBZeeTcJ2tHkDgzIRrUZ1z
 1x8q2PHb0npe0kKbuI2CxxR6cJoax05dnAmWUb393wPWApTfp+xRwzY+CTPOxjNmzj1m
 liDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1736978547; x=1737583347;
 h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
 :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=gT+O2+nkIG0eMoEF25SGVyBBAKSWpQNQwaIvh3Sy8Mg=;
 b=SG9fLquFwX9gKphqneBTm2pqVh8FkCSATvCryfVg5RztQFtmCmG/nGq0RQffbG+3T/
 qcEl45xNiQ4Z1DboeQkxcdm+12bsQEv60my5zjnnzJlBzHeoC2u0hbDbPRWgBwvXmFMP
 uJIsZ/sX1hgQkhYyNlAcyT7cJUC6CW9p0xVA7vweQB1aj7QTOU9HNE4E5F1d4WYpeQaT
 /twKu2ulQpvoasjurdxMj2reMWfRiiNpqnfmWEhjeJDAzK6xUMOeIEZR75g8X0rwvgFa
 9vVeYE9c2PNWzfWpEEZzu5VUQq0rg5WXF/nO9+/JCO8RQxTWSgQA8uMQYKA59OX6kqLx
 uJCw==
X-Forwarded-Encrypted: i=1;
 AJvYcCXFhWHJaj6HWlEMBo053Ptk0kQnuQZYpyWhy7HyCSwIX87uxDF4XH0OJ/OI08X1acXq5uOtgA==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yz7o76Z6GB9l2tx731GvJL4AnSiG3NK8EMavS0XnBnBqdoxyAaW
 OgllycbMn+XG6rsLu2KmizOz34XgQd3YQqYVkQT00DF3o6ugBkVw9CRbaobE1b7EHp/ee4KYxfg
 d3/o06FuzwI6Gw184oMCKCKhlc8M=
X-Gm-Gg: ASbGncuOe5nYNa0tLODFBdJwZogNAtHl7YDoNVqQEpj7JWFrrM8J/OEYz/gbJivQxKZ
 2hBZFm8gBuihEOiRH5iyJN/BYxka5JrxVu5H5Gm7U
X-Google-Smtp-Source: AGHT+IFQzfFS809n1gCS3zrUvRkStNC+FQI7ZVq0VpQMFqg4CGBYMmdzcZ8Z8tfjIGGvOUBwxXac+EO6zWf/3trealw=
X-Received: by 2002:a50:c94b:0:b0:5d9:82df:7fae with SMTP id
 4fb4d7f45d1cf-5d982df811fmr18569524a12.5.1736978547367; Wed, 15 Jan 2025
 14:02:27 -0800 (PST)
Received: from 753933720722 named unknown by gmailapi.google.com with
 HTTPREST; Wed, 15 Jan 2025 17:02:27 -0500
From: Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <8734hjolxs.fsf@HIDDEN>
References: <76c39274-df2a-4340-884f-30da2e51aecb@HIDDEN>
 <87o707275z.fsf@HIDDEN>
 <CADwFkmnN3-8NVFupMAadW58cpDR_fNgKw8nkgQhzmaxMwOFzrg@HIDDEN>
 <8734hjolxs.fsf@HIDDEN>
MIME-Version: 1.0
Date: Wed, 15 Jan 2025 17:02:27 -0500
X-Gm-Features: AbW1kvafW_24cioM6_MKaBg3yD1naRlbbyJzmuPan00WXFPpiEhbjXxIySLKme8
Message-ID: <CADwFkmmdA-6svO44XtQ+x96gkMqFnSZFLddFjsbrsKgC3u9heA@HIDDEN>
Subject: Re: bug#75581: 30.0.93; Crash when copy-sequence on clear-string'ed
 multibyte strings with text properties
To: Pip Cet <pipcet@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75581
Cc: 75581 <at> debbugs.gnu.org, Kanakana <gudzpoz@HIDDEN>,
 Andreas Schwab <schwab@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Pip Cet <pipcet@HIDDEN> writes:

> Looks good to me.  However, on the scratch/no-purespace branch, we need
> to ensure that this function cannot be called on the empty multibyte
> string, turning it into a second empty unibyte string!  I'll push a fix
> to that branch in a bit.

Please do, thanks.

> However, if this function is meant to clear a string from memory
> to prevent leaving confidential data in memory, that won't work with
> MPS.  (I suppose it's reasonably clear that no protection whatsoever
> applies to string properties?)
>
> The problem is MPS allocates string data in a "copying" pool, so several
> copies of the string will usually be present.
>
> alloc.c string compaction may also result in recently-used short strings
> remaining in memory, IIUC, but only if an alloc.c GC cycle happens
> between string creation and the clear-string call.  (But if it does
> happen, it's very likely that a copy of the string is created!)
>
> How important is this feature?  What we have now is better that nothing,
> but if people start relying on it in any way, that's worse than nothing.
> A stern warning in the docstring may help reduce the problem.

I think a stern warning in the docstring makes sense.  This is
potentially security-critical, and we should better make sure that we
can make no guarantees here.

It would be nice if we could have a guaranteed secure way of allocating
and deallocating strings for passwords from ELisp.  Could something like
that be done?  I can think of several dumb and hacky ways to do it, but
none that are clean or smart.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75581; Package emacs. Full text available.

Message received at 75581 <at> debbugs.gnu.org:


Received: (at 75581) by debbugs.gnu.org; 15 Jan 2025 20:51:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 15 15:51:03 2025
Received: from localhost ([127.0.0.1]:58936 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYALu-0007HM-OW
	for submit <at> debbugs.gnu.org; Wed, 15 Jan 2025 15:51:03 -0500
Received: from mail-40131.protonmail.ch ([185.70.40.131]:38645)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
 id 1tYALr-0007Gp-S5
 for 75581 <at> debbugs.gnu.org; Wed, 15 Jan 2025 15:51:01 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1736974253; x=1737233453;
 bh=WDUK7Bdp3C21ZpVT2Qviv3fg0IR8MzvGYi+S598dQQY=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post;
 b=As+3cxcwdRQU0XhlCIQr1Cz9SyVzvrWNir2QmjkOpjevif3CR0pE7X1U+ZflV2re0
 F3Z78/PHdEhfILQhBGfba3ssK3M+YFaP+6uFiUDXxV0WIJW8k9B131FLlCa/WdeLAR
 +5sNVBbKhg1e7woSpsdBuAZ/n4l2otPnzCWlcz2roeIBi8Bs+GIkEz6UVw4OYsvb1n
 nXSB7KIgNHFHe2Arf+JyVXWAel6wI4FVAJ2IhU8P3NDD/1t/qg642Gcr5mN31gUImJ
 m0gnxo9EWIsSxMXa/lE7QYMoOEyvepk0L0olZN68pClsaRgjQhKXPlvSl2lfqaq3eF
 4njgT8nHYvk+A==
Date: Wed, 15 Jan 2025 20:50:48 +0000
To: Stefan Kangas <stefankangas@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#75581: 30.0.93;
 Crash when copy-sequence on clear-string'ed multibyte strings with
 text properties
Message-ID: <87y0zbn6n7.fsf@HIDDEN>
In-Reply-To: <CADwFkmnN3-8NVFupMAadW58cpDR_fNgKw8nkgQhzmaxMwOFzrg@HIDDEN>
References: <76c39274-df2a-4340-884f-30da2e51aecb@HIDDEN>
 <87o707275z.fsf@HIDDEN>
 <CADwFkmnN3-8NVFupMAadW58cpDR_fNgKw8nkgQhzmaxMwOFzrg@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 5042b33d68a366400b06371740770522b552358e
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.8 (-)
X-Debbugs-Envelope-To: 75581
Cc: 75581 <at> debbugs.gnu.org, Kanakana <gudzpoz@HIDDEN>,
 Andreas Schwab <schwab@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.8 (--)

Pip Cet <pipcet@HIDDEN> writes:

> "Stefan Kangas" <stefankangas@HIDDEN> writes:
>
>> Andreas Schwab <schwab@HIDDEN> writes:
>>
>>> On Jan 15 2025, Kanakana wrote:
>>>
>>>> I don't know. Are text properties expected to handle string length
>>>> change via clear-string?
>>>
>>> clear-string should probably remove any text properties.
>>
>> Agreed.  This patch fixes the crash for me:
>>
>> diff --git a/src/fns.c b/src/fns.c
>> index 191154c651a..c48cdf879e4 100644
>> --- a/src/fns.c
>> +++ b/src/fns.c
>> @@ -3315,6 +3315,8 @@ DEFUN ("clear-string", Fclear_string, Sclear_strin=
g,
>>  {
>>    CHECK_STRING (string);
>>    ptrdiff_t len =3D SBYTES (string);
>> +  Fset_text_properties (make_fixnum (0), make_fixnum (SCHARS (string)),
>> +=09=09=09Qnil, string);
>>    if (len !=3D 0 || STRING_MULTIBYTE (string))
>>      {
>>        CHECK_IMPURE (string, XSTRING (string));
>
> Looks good to me.  However, on the scratch/no-purespace branch, we need
> to ensure that this function cannot be called on the empty multibyte
> string, turning it into a second empty unibyte string!  I'll push a fix
> to that branch in a bit.

Sorry, false alarm.  STRING_SET_UNIBYTE modifies its argument in this
case, replacing it by the appropriate empty string (which is unused).

The only difference is that (clear-string "") no longer throws an error,
but I don't see a problem with either behavior in that case.

Pip





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75581; Package emacs. Full text available.

Message received at 75581 <at> debbugs.gnu.org:


Received: (at 75581) by debbugs.gnu.org; 15 Jan 2025 20:49:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 15 15:49:04 2025
Received: from localhost ([127.0.0.1]:58928 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYAJz-00077g-R0
	for submit <at> debbugs.gnu.org; Wed, 15 Jan 2025 15:49:04 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:34742)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tYAJx-000779-BQ
 for 75581 <at> debbugs.gnu.org; Wed, 15 Jan 2025 15:49:01 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1tYAJq-0002FQ-Cf; Wed, 15 Jan 2025 15:48:54 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=+TtfoZdbOSzZnlsHBjpcyv/5/L2Z7d3dJ7NWOZVHb24=; b=j4eS1aQXTntS
 IrcL5U5uYj0iNldVnGzt1SO18A51C5zRCBK6gT2CvoBgu3RfbrFUV16BhzHPH+gVRWC+ZOHJQeXjo
 bFP+QvXZm4lVWRzq4pS0vOMV+bWgZAKqMixd58HNpH8ITK81Z36pq/1grdWxKbQtq1Pkbq5JxXXax
 20X2ysIhRB9lSexQhJ8d+QfTrVytBNkRnP61IxVqTJN1LUm/IwmpL33Rlk3oTXLiy/jgPO59lR0/z
 Z4Kiaoc1ELCGq0GkP80UDinAnYCGIgtsyokYiGS0k+00Nbb2J8R4tKp3rNyImwexFBA6aJqOGbL9J
 yIMcApcvlZJ5yPEn2mAWeA==;
Date: Wed, 15 Jan 2025 22:48:52 +0200
Message-Id: <864j1zkdl7.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <CADwFkmnN3-8NVFupMAadW58cpDR_fNgKw8nkgQhzmaxMwOFzrg@HIDDEN>
 (message from Stefan Kangas on Wed, 15 Jan 2025 15:15:06 -0500)
Subject: Re: bug#75581: 30.0.93;
 Crash when copy-sequence on clear-string'ed multibyte strings with
 text properties
References: <76c39274-df2a-4340-884f-30da2e51aecb@HIDDEN>
 <87o707275z.fsf@HIDDEN>
 <CADwFkmnN3-8NVFupMAadW58cpDR_fNgKw8nkgQhzmaxMwOFzrg@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 75581
Cc: 75581 <at> debbugs.gnu.org, gudzpoz@HIDDEN, schwab@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Cc: 75581 <at> debbugs.gnu.org
> From: Stefan Kangas <stefankangas@HIDDEN>
> Date: Wed, 15 Jan 2025 15:15:06 -0500
> 
> Andreas Schwab <schwab@HIDDEN> writes:
> 
> > On Jan 15 2025, Kanakana wrote:
> >
> >> I don't know. Are text properties expected to handle string length
> >> change via clear-string?
> >
> > clear-string should probably remove any text properties.
> 
> Agreed.  This patch fixes the crash for me:
> 
> diff --git a/src/fns.c b/src/fns.c
> index 191154c651a..c48cdf879e4 100644
> --- a/src/fns.c
> +++ b/src/fns.c
> @@ -3315,6 +3315,8 @@ DEFUN ("clear-string", Fclear_string, Sclear_string,
>  {
>    CHECK_STRING (string);
>    ptrdiff_t len = SBYTES (string);
> +  Fset_text_properties (make_fixnum (0), make_fixnum (SCHARS (string)),
> +			Qnil, string);
>    if (len != 0 || STRING_MULTIBYTE (string))
>      {
>        CHECK_IMPURE (string, XSTRING (string));

Thanks, but please also document this aspect of the function's
behavior in both the doc string and in the ELisp manual.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75581; Package emacs. Full text available.

Message received at 75581 <at> debbugs.gnu.org:


Received: (at 75581) by debbugs.gnu.org; 15 Jan 2025 20:35:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 15 15:35:25 2025
Received: from localhost ([127.0.0.1]:58912 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tYA6m-0006ZV-P2
	for submit <at> debbugs.gnu.org; Wed, 15 Jan 2025 15:35:25 -0500
Received: from mail-10630.protonmail.ch ([79.135.106.30]:52241)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
 id 1tYA6h-0006Z6-FJ
 for 75581 <at> debbugs.gnu.org; Wed, 15 Jan 2025 15:35:23 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1736973311; x=1737232511;
 bh=QF0m/LHaXyl6QytFgy9J4//44FsDTExGTFGDNnV/8W0=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post;
 b=haWwlcYfxiGqwPsku7os4M75bzHhAWS4TNX7x/zNkuHPRRKZB8IpwN32EmTQTktbe
 S1dhC79G/MQGlHmZD1EhKfirflAGpvPvZndvZfswIH00qX/l7ImNwcX3usQ4gqWoBz
 mztpqywSi/AAt6Z+zHpREkuzV3FB3/usbMe4Nn8l9BCRlNKqPOe8RhSaeNLdXibHXn
 QUqN4HkROt+wygUE8mtCp3X0ZX7JafkxGCcER4Vg2+qHlAvPu8ldCUhYn/Jks0qARl
 F9AvUt67YLSxWzIl6zf2Stennm9Tm8Iu6T5GQAGUCd83U7fiI/3Ex/HksKHrpwCDU/
 p7oWDPlyk9MQA==
Date: Wed, 15 Jan 2025 20:35:07 +0000
To: Stefan Kangas <stefankangas@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#75581: 30.0.93;
 Crash when copy-sequence on clear-string'ed multibyte strings with
 text properties
Message-ID: <8734hjolxs.fsf@HIDDEN>
In-Reply-To: <CADwFkmnN3-8NVFupMAadW58cpDR_fNgKw8nkgQhzmaxMwOFzrg@HIDDEN>
References: <76c39274-df2a-4340-884f-30da2e51aecb@HIDDEN>
 <87o707275z.fsf@HIDDEN>
 <CADwFkmnN3-8NVFupMAadW58cpDR_fNgKw8nkgQhzmaxMwOFzrg@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 627d4d2e2d1c43d85e8b883be5e4e7a08ff5fabc
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75581
Cc: 75581 <at> debbugs.gnu.org, Kanakana <gudzpoz@HIDDEN>,
 Andreas Schwab <schwab@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

"Stefan Kangas" <stefankangas@HIDDEN> writes:

> Andreas Schwab <schwab@HIDDEN> writes:
>
>> On Jan 15 2025, Kanakana wrote:
>>
>>> I don't know. Are text properties expected to handle string length
>>> change via clear-string?
>>
>> clear-string should probably remove any text properties.
>
> Agreed.  This patch fixes the crash for me:
>
> diff --git a/src/fns.c b/src/fns.c
> index 191154c651a..c48cdf879e4 100644
> --- a/src/fns.c
> +++ b/src/fns.c
> @@ -3315,6 +3315,8 @@ DEFUN ("clear-string", Fclear_string, Sclear_string=
,
>  {
>    CHECK_STRING (string);
>    ptrdiff_t len =3D SBYTES (string);
> +  Fset_text_properties (make_fixnum (0), make_fixnum (SCHARS (string)),
> +=09=09=09Qnil, string);
>    if (len !=3D 0 || STRING_MULTIBYTE (string))
>      {
>        CHECK_IMPURE (string, XSTRING (string));

Looks good to me.  However, on the scratch/no-purespace branch, we need
to ensure that this function cannot be called on the empty multibyte
string, turning it into a second empty unibyte string!  I'll push a fix
to that branch in a bit.

However, if this function is meant to clear a string from memory
to prevent leaving confidential data in memory, that won't work with
MPS.  (I suppose it's reasonably clear that no protection whatsoever
applies to string properties?)

The problem is MPS allocates string data in a "copying" pool, so several
copies of the string will usually be present.

alloc.c string compaction may also result in recently-used short strings
remaining in memory, IIUC, but only if an alloc.c GC cycle happens
between string creation and the clear-string call.  (But if it does
happen, it's very likely that a copy of the string is created!)

How important is this feature?  What we have now is better that nothing,
but if people start relying on it in any way, that's worse than nothing.
A stern warning in the docstring may help reduce the problem.

Pip





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75581; Package emacs. Full text available.

Message received at 75581 <at> debbugs.gnu.org:


Received: (at 75581) by debbugs.gnu.org; 15 Jan 2025 20:15:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 15 15:15:17 2025
Received: from localhost ([127.0.0.1]:58843 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tY9nJ-0003LI-35
	for submit <at> debbugs.gnu.org; Wed, 15 Jan 2025 15:15:17 -0500
Received: from mail-ed1-x529.google.com ([2a00:1450:4864:20::529]:59437)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>)
 id 1tY9nF-0002tc-4F
 for 75581 <at> debbugs.gnu.org; Wed, 15 Jan 2025 15:15:13 -0500
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-5d3bbb0f09dso250560a12.2
 for <75581 <at> debbugs.gnu.org>; Wed, 15 Jan 2025 12:15:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1736972107; x=1737576907; darn=debbugs.gnu.org;
 h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
 :from:from:to:cc:subject:date:message-id:reply-to;
 bh=jemaO8IuurslHlUiEsw90zmQ9DeARAooGFzKxbw1qrE=;
 b=PQD1/HS/2HsleydK7F4rJq1k/bBj6rwWUrJhgzu9QLe6itPgidnAry0r5iAv9NFPhv
 w+N5JiVfBp8q8rYjFYeuPUP3gqbAc5F2lNzPr2U5qsHoOn7mFyqEqHfMU56Px52FCCcy
 1GUXeduoVdFky2nskVkZ2hQHGw2rU3z2QeP3L8ooOMrBkoEH4O7AEUDmEmLgPHAvPtjv
 BX1ErPuKTEbs3EpRyRO5GS1N8YfbRNzdubzB1k6BS5oWuSBHRIBVzi7p5WnoAw+/WIsC
 7Jex0aU1HZRuc7VyDIrAmoO83AU/cH7W6nj5+Yv0gudQ8Rc7Yf3nUA0puChYARBmeAaX
 Bwbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1736972107; x=1737576907;
 h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
 :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=jemaO8IuurslHlUiEsw90zmQ9DeARAooGFzKxbw1qrE=;
 b=kpiAVXoMi9pV80JG4Lc6Im+T9uWaYZp4AoRNgTn3OknWUlaCKU6ob0+UJdB+334f6u
 kpbWSMBHnWGyrt4SUOTRde/nQmw/qgq4izzyvHShr3+5O5iNUaEXILG3vOfaV0VBv92L
 Tr8fTo1BhwSoHMC0tkpit57coUzP4IM6agemFONOtZVYayj0a7qGQpXuGkYrbcZFuWcA
 eq2RuEQFbJLqYalm+m++gNQh3/gJDtka3Ou+woZ5JqCFF0fOW7iWdB1KXmmYen47esQI
 e0Q8Il1++bayIXIAd7ALp5+IqRiJTMWtr/bCuwQyx4ge+zCJ5M4U1IxtcB8xof7ck8aQ
 L8RA==
X-Gm-Message-State: AOJu0YyKTbClqNYz1F4HKxi5ssMxyVgG98a8//hJKc/Fcv1k4oHBoi+n
 hiv/cVYkt3VANQHsDok88iSXCaIV5x6yt3wrBjwWbQkE1iWrUG7rLTV1PqDo793qo4eu7mZ3zwU
 /TYfVzo74QU7nRUYLDmOCn/3ZxGTvmQ==
X-Gm-Gg: ASbGnctuy6E8zeHVSSPiOVfhCc/b9wjfoKNCdG3gssDk/XTRqW4TwZipREt9dhfSSek
 6dOIt8aOE06TA5U7ACNUDOECi76SqYQgLBjO7z38I
X-Google-Smtp-Source: AGHT+IE6VpaBovvPGKW3KBhmRmApiDDWnD8pxo9XmETKYulIBsFj6rtULxbAAblgfqEQXelQ8wR5gp5a6T6ttY5QRWA=
X-Received: by 2002:a05:6402:2105:b0:5d0:bf27:ef8a with SMTP id
 4fb4d7f45d1cf-5d972e4eeb6mr27851177a12.26.1736972106668; Wed, 15 Jan 2025
 12:15:06 -0800 (PST)
Received: from 753933720722 named unknown by gmailapi.google.com with
 HTTPREST; Wed, 15 Jan 2025 15:15:06 -0500
From: Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <87o707275z.fsf@HIDDEN>
References: <76c39274-df2a-4340-884f-30da2e51aecb@HIDDEN>
 <87o707275z.fsf@HIDDEN>
MIME-Version: 1.0
Date: Wed, 15 Jan 2025 15:15:06 -0500
X-Gm-Features: AbW1kvYC4pGQh0L8KCuQyq46XNDCt6Kv9W0nSc9ILTu__JrGzgKAUu-cm5eA3q0
Message-ID: <CADwFkmnN3-8NVFupMAadW58cpDR_fNgKw8nkgQhzmaxMwOFzrg@HIDDEN>
Subject: Re: bug#75581: 30.0.93; Crash when copy-sequence on clear-string'ed
 multibyte strings with text properties
To: Andreas Schwab <schwab@HIDDEN>, Kanakana <gudzpoz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75581
Cc: 75581 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Andreas Schwab <schwab@HIDDEN> writes:

> On Jan 15 2025, Kanakana wrote:
>
>> I don't know. Are text properties expected to handle string length
>> change via clear-string?
>
> clear-string should probably remove any text properties.

Agreed.  This patch fixes the crash for me:

diff --git a/src/fns.c b/src/fns.c
index 191154c651a..c48cdf879e4 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -3315,6 +3315,8 @@ DEFUN ("clear-string", Fclear_string, Sclear_string,
 {
   CHECK_STRING (string);
   ptrdiff_t len = SBYTES (string);
+  Fset_text_properties (make_fixnum (0), make_fixnum (SCHARS (string)),
+			Qnil, string);
   if (len != 0 || STRING_MULTIBYTE (string))
     {
       CHECK_IMPURE (string, XSTRING (string));




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75581; Package emacs. Full text available.

Message received at 75581 <at> debbugs.gnu.org:


Received: (at 75581) by debbugs.gnu.org; 15 Jan 2025 19:45:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 15 14:45:02 2025
Received: from localhost ([127.0.0.1]:58781 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tY9K1-0001Az-SJ
	for submit <at> debbugs.gnu.org; Wed, 15 Jan 2025 14:45:02 -0500
Received: from mail-out.m-online.net ([2001:a60:0:28:0:1:25:1]:57983)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <whitebox@HIDDEN>)
 id 1tY9Jz-0001Af-P0
 for 75581 <at> debbugs.gnu.org; Wed, 15 Jan 2025 14:45:00 -0500
Received: from frontend01.mail.m-online.net (unknown [192.168.8.182])
 by mail-out.m-online.net (Postfix) with ESMTP id 4YYGfy0CCyz1syBn;
 Wed, 15 Jan 2025 20:44:57 +0100 (CET)
Received: from localhost (dynscan1.mnet-online.de [192.168.6.68])
 by mail.m-online.net (Postfix) with ESMTP id 4YYGfx4Mj9z1qqlS;
 Wed, 15 Jan 2025 20:44:57 +0100 (CET)
X-Virus-Scanned: amavis at mnet-online.de
Received: from mail.mnet-online.de ([192.168.8.182])
 by localhost (dynscan1.mail.m-online.net [192.168.6.68]) (amavis, port 10024)
 with ESMTP id jIzxX6zPAX57; Wed, 15 Jan 2025 20:44:56 +0100 (CET)
X-Auth-Info: btwW0ELMcvlsIacnqkBdSSbQ8BGALAHlTIOYquqktuo0lR6eIlTSs/qc8nRE+RG5
Received: from igel.home (aftr-82-135-83-199.dynamic.mnet-online.de
 [82.135.83.199])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by mail.mnet-online.de (Postfix) with ESMTPSA;
 Wed, 15 Jan 2025 20:44:56 +0100 (CET)
Received: by igel.home (Postfix, from userid 1000)
 id 2EF942C1C60; Wed, 15 Jan 2025 20:44:56 +0100 (CET)
From: Andreas Schwab <schwab@HIDDEN>
To: Kanakana <gudzpoz@HIDDEN>
Subject: Re: bug#75581: 30.0.93; Crash when copy-sequence on clear-string'ed
 multibyte strings with text properties
In-Reply-To: <76c39274-df2a-4340-884f-30da2e51aecb@HIDDEN> (Kanakana's
 message of "Wed, 15 Jan 2025 18:48:30 +0800")
References: <76c39274-df2a-4340-884f-30da2e51aecb@HIDDEN>
Date: Wed, 15 Jan 2025 20:44:56 +0100
Message-ID: <87o707275z.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.5 (/)
X-Debbugs-Envelope-To: 75581
Cc: 75581 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.5 (-)

On Jan 15 2025, Kanakana wrote:

> I don't know. Are text properties expected to handle string length
> change via clear-string?

clear-string should probably remove any text properties.

-- 
Andreas Schwab, schwab@HIDDEN
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#75581; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 15 Jan 2025 14:36:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 15 09:36:30 2025
Received: from localhost ([127.0.0.1]:57346 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tY4VS-0003hy-7m
	for submit <at> debbugs.gnu.org; Wed, 15 Jan 2025 09:36:30 -0500
Received: from lists.gnu.org ([2001:470:142::17]:53786)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <gudzpoz@HIDDEN>) id 1tY0x6-0006kY-Q0
 for submit <at> debbugs.gnu.org; Wed, 15 Jan 2025 05:48:49 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10])
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <gudzpoz@HIDDEN>) id 1tY0wz-0000a3-Bm
 for bug-gnu-emacs@HIDDEN; Wed, 15 Jan 2025 05:48:41 -0500
Received: from mail-pl1-x62b.google.com ([2607:f8b0:4864:20::62b])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <gudzpoz@HIDDEN>) id 1tY0wx-000617-6Y
 for bug-gnu-emacs@HIDDEN; Wed, 15 Jan 2025 05:48:41 -0500
Received: by mail-pl1-x62b.google.com with SMTP id
 d9443c01a7336-219f8263ae0so107905895ad.0
 for <bug-gnu-emacs@HIDDEN>; Wed, 15 Jan 2025 02:48:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1736938116; x=1737542916; darn=gnu.org;
 h=content-transfer-encoding:content-language:to:subject:from
 :user-agent:mime-version:date:message-id:from:to:cc:subject:date
 :message-id:reply-to;
 bh=KnbstmLhm7ZaDs/Yd/R/KgDm5jW2moRdQ3wBTRhq01U=;
 b=UcK/Y5yMfHTWASscIp4l/kClZdjGb6QslCcqRc0f4z98vCAofrs4O/JWfA0OsOTUPM
 ofyTsDe8c0aILR3sfZiCx2iVSd+vdLlMxs5LWJJ9thr9XuTviLMOfUtR/rsw4zdOJVKD
 ww+9BtQg/sHQSvMuozcpacGwkFSseUUdWjOr1bFWZnX7C0WZemVRuiypThu17YhwX79a
 YYIroFE4sLI07vTx8Wi4nCAVxGWtbRfrbtPzKlWTvvnN8nwpDrRxgVZU1GoXyVX3H1LW
 Ue97WP1HjxtHozoT+TtzpohNvRhsXnOZvi+jeA3m1dG3uZyULS2QJiBohEF3vg0PRGQF
 95pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1736938116; x=1737542916;
 h=content-transfer-encoding:content-language:to:subject:from
 :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
 :cc:subject:date:message-id:reply-to;
 bh=KnbstmLhm7ZaDs/Yd/R/KgDm5jW2moRdQ3wBTRhq01U=;
 b=QkIrnorPWatcujY39q034OtG1sY2boqOYZyW72Xuq5PV9jxFLsEvisNbWw9N/ln516
 GgMv4QvfBczN4S+L27ZaRRGyWx8NGd3bXfrDqr5Z1PQ5/LDiBQFUTJB8+ONX+d4BJ9FZ
 PjPtUxqO3w3YafSPA0PUBmNlDVD9mdE4P9rf//hB1Z5HfxegzhWRRRPLErOE6INPZrnW
 hOIukPbFInb8Vb6eQ4S/bmxryACKqWWz9NgO6x7JuQwwshgmnfo6MApayDl+4Z9J/xJc
 FM8dNF0pYGUZGWE4s+QdmN7efDGChTvGG1PP1aqytHPBhbnbRHjJWIkftD+ZCxhzh/OR
 w2PA==
X-Gm-Message-State: AOJu0YwkkFKYHRDmAc1Y/su9shClwCOnww3byGc1PXqtPUF2dD+jlsUH
 NDMGUtuWt6SWXKXt9sOq2bp4blUfKsXzcOgNgIaLh0jgeX+s3/y9zOlEkhwe
X-Gm-Gg: ASbGnctrykGRHGdaT9zbWN2LPri9L26O5fx2nGkLHTs1wwcIJuB4ULfYvEKYAq9vjFq
 RetjoRkRcd0evWlhf5mzM6yUI6fpl32ZQAm5B+nIdQeQ6ZoB4SpkWD1VzRcEpWNYaCcd89+2Z6q
 MNYoU9z48rtChX/QVn5N0idtO7sc/STOzJZ1Ef5dB3tZRGA86cbTXIB4SdXRuqon/dMMV+/NUTP
 Yb23kc6e/Gay+uJPbj6lUTwXuLkZ3sP4a5pkAPb0kaEfVq6WoJHky8LZSVYWhzkzTkWNF/FvTt4
 r0o=
X-Google-Smtp-Source: AGHT+IFyAZndXu0rnfYcEcjtV0sQC70uGtzArawxDeRqU31sEKgbmrFYR8L/6/JXvINfF8FYDIyzKw==
X-Received: by 2002:a17:903:18b:b0:215:577b:ab77 with SMTP id
 d9443c01a7336-21a83fc0197mr410789835ad.39.1736938116384; 
 Wed, 15 Jan 2025 02:48:36 -0800 (PST)
Received: from [127.0.0.1] (vmi1363604.contaboserver.net. [5.104.81.25])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-21a9f12aa9dsm79956675ad.62.2025.01.15.02.48.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 15 Jan 2025 02:48:35 -0800 (PST)
Message-ID: <76c39274-df2a-4340-884f-30da2e51aecb@HIDDEN>
Date: Wed, 15 Jan 2025 18:48:30 +0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Kanakana <gudzpoz@HIDDEN>
Subject: 30.0.93; Crash when copy-sequence on clear-string'ed multibyte
 strings with text properties
To: bug-gnu-emacs@HIDDEN
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=2607:f8b0:4864:20::62b;
 envelope-from=gudzpoz@HIDDEN; helo=mail-pl1-x62b.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: submit
X-Mailman-Approved-At: Wed, 15 Jan 2025 09:36:27 -0500
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

** Reproducing Steps

Run:

     emacs -Q --batch --eval '(let ((s #("🤗" 0 1 (prop value)))) 
(clear-string s) (copy-sequence s))'


** Expected Behavior

I don't know. Are text properties expected to handle string length
change via clear-string?

** Observed Symptoms

Emacs crashes, with stack trace saying:

#+begin_verse
#0 0x00005555557e2a58 in copy_intervals ()
#1 0x000055555576dfc4 in Fcopy_sequence ()
#2 0x0000555555765c65 in eval_sub ()
#3 0x0000555555769080 in Flet ()
#4 0x0000555555765b0a in eval_sub ()
#5 0x0000555555766353 in Feval ()
#6 0x0000555555766eee in Ffuncall ()
#7 0x00007fffeed925b6 in F636f6d6d616e642d6c696e652d31_command_line_1_0 ()
from 
/usr/bin/../lib/emacs/30.0.93/native-lisp/30.0.93-3fae9fb4/preloaded/startup-bbc6ea72-bc20aae4.eln
#8 0x0000555555766eee in Ffuncall ()
#9 0x00007fffeed890a7 in F636f6d6d616e642d6c696e65_command_line_0 ()
from 
/usr/bin/../lib/emacs/30.0.93/native-lisp/30.0.93-3fae9fb4/preloaded/startup-bbc6ea72-bc20aae4.eln
#10 0x0000555555766eee in Ffuncall ()
#11 0x00007fffeed85500 in 
F6e6f726d616c2d746f702d6c6576656c_normal_top_level_0 ()
from 
/usr/bin/../lib/emacs/30.0.93/native-lisp/30.0.93-3fae9fb4/preloaded/startup-bbc6ea72-bc20aae4.eln
#12 0x0000555555765aff in eval_sub ()
#13 0x0000555555766353 in Feval ()
#14 0x00005555556cbe3e in top_level_2 ()
#15 0x0000555555762127 in internal_condition_case ()
#16 0x00005555556cc97b in top_level_1 ()
#17 0x000055555576206a in internal_catch ()
#18 0x00005555556cbd46 in command_loop ()
#19 0x00005555556d3cad in recursive_edit_1 ()
#20 0x00005555556d4066 in Frecursive_edit ()
#21 0x00005555555e2428 in main ()
#+end_verse

(Also reproduced in an Emacs 29.1 AppImage from
https://github.com/blahgeek/emacs-appimage/releases/20240102-1200 .)

In GNU Emacs 30.0.93 (build 2, x86_64-pc-linux-gnu, GTK+ Version
3.24.43, cairo version 1.18.2) of 2025-01-15 built on lil-end
Repository revision: b981889e9ee0a37f1bc8e2c9b90a5d154c1d032e
Repository branch: makepkg
System Description: EndeavourOS

Configured using:
'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
--localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games
--with-modules --without-m17n-flt --without-gconf
--with-native-compilation=yes --with-xinput2 --with-pgtk
--without-xaw3d --with-sound=no --with-tree-sitter --without-gpm
--without-compress-install
'--program-transform-name=s/\([ec]tags\)/\1.emacs/'
'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions
-Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
-fstack-clash-protection -fcf-protection'
LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now
'CXXFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions
-Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
-fstack-clash-protection -fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PGTK PNG RSVG SECCOMP SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP XIM GTK3 ZLIB

Important settings:
value of $LC_MONETARY: en_US.UTF-8
value of $LC_NUMERIC: en_US.UTF-8
value of $LC_TIME: en_US.UTF-8
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: fcitx
locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-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
minibuffer-regexp-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x 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 rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/pgtk-win pgtk-win term/common-win touch-screen pgtk-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-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 nadvice seq simple cl-generic
indonesian philippine 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 emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo gtk pgtk
lcms2 multi-tty move-toolbar make-network-process native-compile emacs)

Memory information:
((conses 16 49610 11031) (symbols 48 5334 0) (strings 32 13417 2300)
(string-bytes 1 392723) (vectors 16 8817)
(vector-slots 8 124703 9243) (floats 8 22 12) (intervals 56 397 0)
(buffers 992 11))




Acknowledgement sent to Kanakana <gudzpoz@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#75581; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Thu, 16 Jan 2025 12:30:02 UTC

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