Subject: Re: bug#75581: 30.0.93; Crash when copy-sequence on clear-string'ed multibyte strings with text properties

From: Pip Cet <[email-masked]>
Date: Wed, 15 Jan 2025 20:50:48 +0000

Pip Cet <[email-masked]> writes:

> "Stefan Kangas" <[email-masked]> writes:
>
>> Andreas Schwab <[email-masked]> 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));
>
> 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