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
bug-gnu-emacs@HIDDEN
:bug#75581
; Package emacs
.
Full text available.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.
bug-gnu-emacs@HIDDEN
:bug#75581
; Package emacs
.
Full text available.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
bug-gnu-emacs@HIDDEN
:bug#75581
; Package emacs
.
Full text available.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
bug-gnu-emacs@HIDDEN
:bug#75581
; Package emacs
.
Full text available.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
bug-gnu-emacs@HIDDEN
:bug#75581
; Package emacs
.
Full text available.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.
bug-gnu-emacs@HIDDEN
:bug#75581
; Package emacs
.
Full text available.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.
bug-gnu-emacs@HIDDEN
:bug#75581
; Package emacs
.
Full text available.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
bug-gnu-emacs@HIDDEN
:bug#75581
; Package emacs
.
Full text available.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
bug-gnu-emacs@HIDDEN
:bug#75581
; Package emacs
.
Full text available.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.
bug-gnu-emacs@HIDDEN
:bug#75581
; Package emacs
.
Full text available.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?
Kanakana <gudzpoz@HIDDEN>
:Stefan Kangas <stefankangas@HIDDEN>
: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.
bug-gnu-emacs@HIDDEN
:bug#75581
; Package emacs
.
Full text available.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
bug-gnu-emacs@HIDDEN
:bug#75581
; Package emacs
.
Full text available.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.
bug-gnu-emacs@HIDDEN
:bug#75581
; Package emacs
.
Full text available.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
bug-gnu-emacs@HIDDEN
:bug#75581
; Package emacs
.
Full text available.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));
bug-gnu-emacs@HIDDEN
:bug#75581
; Package emacs
.
Full text available.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."
bug-gnu-emacs@HIDDEN
:bug#75581
; Package emacs
.
Full text available.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))
Kanakana <gudzpoz@HIDDEN>
:bug-gnu-emacs@HIDDEN
.
Full text available.bug-gnu-emacs@HIDDEN
:bug#75581
; Package emacs
.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.