[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#44349: 28.0.50; Assertion failure on macOS when resizing frame
From: |
Alan Third |
Subject: |
bug#44349: 28.0.50; Assertion failure on macOS when resizing frame |
Date: |
Sun, 29 Nov 2020 17:16:23 +0000 |
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