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

From: Eli Zaretskii <[email-masked]>
Date: Tue, 27 May 2025 21:27:43 +0300

> Date: Tue, 27 May 2025 18:05:00 +0000
> From: Pip Cet <[email-masked]>
> Cc: [email-masked]
> 
> "Eli Zaretskii" <[email-masked]> writes:
> 
> > I agree that the current code is buggy because it keeps referencing a
> > Lisp string's data via a 'char *' pointer while calling a Lisp
> > function PRINTCHARFUN.
> 
> How about calling Fmapc (printcharfun, string) at that point, from
> print_string?

If that works, fine.  But didn't you say below that print_string does
something we don't want to do in this case?  Or am I misunderstanding
what you mean?

> > 	      int len, ch = (string_char_and_length
> > 			     ((const unsigned char *) ptr + i, &len));
> > use
> >
> > 	      int len, ch = (string_char_and_length
> > 			     (SDATA (string) + i, &len));
> >
> > where 'string' is the original Lisp string to print?
> 
> That's what print_string does (even though it should be more careful,
> which is most easily achieved by delegating to Fmapc and fixing that).

Yes.

> It does, however, also transform the string by escaping some characters,
> which seems incorrect to me in these circumstances (and would mean
> changing existing behavior).

So calling print_string as it is will not do what we want, right?

> > If this requires adding an additional argument to strout, to pass the
> > Lisp string, which will be used only in the last 'else' clause there,
> > that's not difficult, right?
> 
> But we already have print_string, which does almost exactly that, right?
> All it needs is an extra argument to avoid the byte8 escaping (unless
> I'm wrong and we actually want that to happen to our string here).

Sure, that works as well, I think (though I took only a cursory look
at print_string, so maybe I missed something).

The important part, I think, is to avoid duplicating the string if we
can avoid that.