GNU bug report logs -
#78590
31.0.50; print_object calls strout unsafely
Previous Next
Full log
Message #17 received at 78590 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 27 May 2025 18:05:00 +0000
> From: Pip Cet <pipcet <at> protonmail.com>
> Cc: 78590 <at> debbugs.gnu.org
>
> "Eli Zaretskii" <eliz <at> gnu.org> 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.
This bug report was last modified 18 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.