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

[Alan Third]

On Sat, Nov 28, 2020 at 09:51:57AM +0200, Eli Zaretskii wrote:
> > Date: Fri, 27 Nov 2020 22:24:29 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: Philipp Stephani <p.stephani2@gmail.com>, 44349@debbugs.gnu.org
> > 
> > Patch attached.
> > 
> > I can't see any other special cases that need to be handled and all my
> > tests worked, so I think this is all that's needed.
> 
> Thanks!  Can we add tests for this?

I was wondering that. How do we add tests for internal C functions?

> > +          /* doprnt_non_null_end doesn't know about multibyte
> > +             characters so can truncate format in the middle of one.
> > +             If that happens just ignore that character.  */
> 
> Is this because the buffer size is measured in characters, not bytes?
> Or are there other situations where this could happen?  Can you give
> an example?
> 
> 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). I
suppose that's the caller's fault and it's probably not up to doprnt
to "fix" it. You would get the same effect by passing doprnt a format
string that ends "inside" a multibyte char.

This is slightly complicated by the fact that I think we want to
truncate the output on a character boundary if we run out of output
buffer, but if the format string is already truncated inside a
multibyte character then we want to output everything that's there.
Something like:

        {
          int charlen = BYTES_BY_CHAR_HEAD (fmtchar);
          src = fmt0;

          /* If the format string ends in the middle of a multibyte
             character we don't want to skip over the null byte.  */
          for (srclen = 1 ; *(src + srclen) != 0 && srclen < charlen ; 
srclen++);

          fmt = src + srclen;
        }

As for the old code, as far as I can see it implicitly assumed the
format string was always unibyte and do didn't do anything special if
the buffer ran out in the middle of a multibyte character, but you can
see that it took special care not to truncate a multibyte character in
the other data, e.g. a curved quote or a non-format string (doit1).
-- 
Alan Third