From: Alan Third <alan@idiocy.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 44349@debbugs.gnu.org, p.stephani2@gmail.com
Subject: bug#44349: 28.0.50; Assertion failure on macOS when resizing frame
Date: Sat, 28 Nov 2020 22:06:45 +0000 [thread overview]
Message-ID: <20201128220645.GF26836@breton.holly.idiocy.org> (raw)
In-Reply-To: <835z5por4y.fsf@gnu.org>
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
next prev parent reply other threads:[~2020-11-28 22:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-31 15:51 bug#44349: 28.0.50; Assertion failure on macOS when resizing frame Philipp
2020-10-31 15:57 ` Philipp Stephani
2020-10-31 16:03 ` Philipp Stephani
2020-10-31 16:35 ` Eli Zaretskii
2020-10-31 16:43 ` Philipp Stephani
2020-10-31 16:52 ` Eli Zaretskii
2020-11-27 22:24 ` Alan Third
2020-11-28 7:51 ` Eli Zaretskii
2020-11-28 22:06 ` Alan Third [this message]
2020-11-29 10:27 ` Lars Ingebrigtsen
2020-11-29 15:10 ` Eli Zaretskii
2020-11-29 17:16 ` Alan Third
2020-11-29 17:23 ` Eli Zaretskii
2020-11-29 17:43 ` Alan Third
2020-11-01 0:55 ` Alan Third
2020-11-01 0:58 ` Alan Third
2020-11-01 1:00 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201128220645.GF26836@breton.holly.idiocy.org \
--to=alan@idiocy.org \
--cc=44349@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=p.stephani2@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).