Subject: Re: bug#78590: 31.0.50; print_object calls strout unsafely

From: Eli Zaretskii <[email-masked]>
Date: Wed, 28 May 2025 16:54:07 +0300

> Date: Wed, 28 May 2025 13:44:32 +0000
> From: Pip Cet <[email-masked]>
> Cc: [email-masked]
> 
> "Eli Zaretskii" <[email-masked]> writes:
> 
> >> Date: Tue, 27 May 2025 18:46:24 +0000
> >> From: Pip Cet <[email-masked]>
> >> Cc: [email-masked]
> >>
> >> "Eli Zaretskii" <[email-masked]> writes:
> >>
> >>    else
> >>      {
> >> -      /* Otherwise, string may be relocated by printing one char.
> >> -	 So re-fetch the string address for each character.  */
> >> -      ptrdiff_t i;
> >> -      ptrdiff_t size = SCHARS (string);
> >> -      ptrdiff_t size_byte = SBYTES (string);
> >> -      if (size == size_byte)
> >> -	for (i = 0; i < size; i++)
> >> -	  printchar (SREF (string, i), printcharfun);
> >> -      else
> >> -	for (i = 0; i < size_byte; )
> >> -	  {
> >> -	    /* Here, we must convert each multi-byte form to the
> >> -	       corresponding character code before handing it to PRINTCHAR.  */
> >> -	    int len, ch = string_char_and_length (SDATA (string) + i, &len);
> >> -	    printchar (ch, printcharfun);
> >> -	    i += len;
> >> -	  }
> >> +      /* printcharfun is a Lisp function.  */
> >> +      Fmapc (printcharfun, string);
> >
> > What is the rationale for calling Fmapc here?  Doesn't it do in this
> > case what the original code did, but at a price of two additional
> > levels of function calls?  IOW, why did you want to get rid of the
> > original code above?
> 
> Let's leave out that hunk for now?  We can replace it by Fmapc when
> Fmapc is fixed for bug#75845.  I see calling mapc on a record crashes
> now, so I'll try to come up with an updated patch for bug#75845 that
> fixes both that issue and the self-modification thing.

Fine by me, thanks.

So feel free to install on the master branch.