bug#44349: 28.0.50; Assertion failure on macOS when resizing frame

[Alan Third <alan@idiocy.org>]

On Sun, Nov 29, 2020 at 05:10:03PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 28 Nov 2020 22:06:45 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: p.stephani2@gmail.com, 44349@debbugs.gnu.org
> > 
> > > Thanks!  Can we add tests for this?
> > 
> > I was wondering that. How do we add tests for internal C functions?
> 
> By calling Lisp functions which call them.  But maybe it isn't
> possible in this case.
> 
> Wait, isn't the use case which caused this bug report a suitable test
> for the change?

It requires a frame to be resized with the mouse, we don't have a way
of doing that from lisp.

I can't see any way of using lisp functions to test doprnt, it's
mostly used in formatting error messages and other small bits and pieces.

> > > Silently ignoring parts of input sounds ... unusual, so I wonder what
> > > would it take to avoid that.  How did the old code avoid this problem?
> > 
> > This situation can only be caused by calling doprnt with format_end
> > set to some point inside a multibyte character (it's a pointer).
> 
> Ah, okay.  In that case, I think ignoring the invalid sequence is OK,
> but let's document that in the function's commentary.

I think, having thought about it more, I'd prefer to just pass through
the malformed input. If we want to make sure that putting format_end
in the middle of a multibyte character doesn't break anything I think
we'd be better fixing doprnt_non_null_end to cut the string up neatly.

format_end isn't currently used anywhere in Emacs, so I don't know if
it's worth fixing, but I'll add a FIXME comment.

-- 
Alan Third