From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#44349: 28.0.50; Assertion failure on macOS when resizing frame Date: Sat, 28 Nov 2020 09:51:57 +0200 Message-ID: <835z5por4y.fsf@gnu.org> References: <83eelegxq6.fsf@gnu.org> <83a6w2gwxz.fsf@gnu.org> <20201127222429.GD26836@breton.holly.idiocy.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5459"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 44349@debbugs.gnu.org, p.stephani2@gmail.com To: Alan Third Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Nov 28 08:53:26 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kiv2s-0001KG-HC for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 28 Nov 2020 08:53:26 +0100 Original-Received: from localhost ([::1]:40948 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kiv2q-0002eJ-M0 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 28 Nov 2020 02:53:24 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40928) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kiv2U-0002e4-61 for bug-gnu-emacs@gnu.org; Sat, 28 Nov 2020 02:53:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35342) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kiv2T-0003y2-SP for bug-gnu-emacs@gnu.org; Sat, 28 Nov 2020 02:53:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kiv2T-00011j-J6 for bug-gnu-emacs@gnu.org; Sat, 28 Nov 2020 02:53:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Nov 2020 07:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44349 X-GNU-PR-Package: emacs Original-Received: via spool by 44349-submit@debbugs.gnu.org id=B44349.16065499393895 (code B ref 44349); Sat, 28 Nov 2020 07:53:01 +0000 Original-Received: (at 44349) by debbugs.gnu.org; 28 Nov 2020 07:52:19 +0000 Original-Received: from localhost ([127.0.0.1]:46888 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kiv1n-00010k-2b for submit@debbugs.gnu.org; Sat, 28 Nov 2020 02:52:19 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:50842) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kiv1l-00010Z-Nu for 44349@debbugs.gnu.org; Sat, 28 Nov 2020 02:52:18 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:41522) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kiv1f-0003re-RH; Sat, 28 Nov 2020 02:52:11 -0500 Original-Received: from [176.228.60.248] (port=1881 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kiv1f-0000Vh-6Z; Sat, 28 Nov 2020 02:52:11 -0500 In-Reply-To: <20201127222429.GD26836@breton.holly.idiocy.org> (message from Alan Third on Fri, 27 Nov 2020 22:24:29 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:194475 Archived-At: > Date: Fri, 27 Nov 2020 22:24:29 +0000 > From: Alan Third > Cc: Philipp Stephani , 44349@debbugs.gnu.org > > > I don't see why we would want to enforce that, it sounds like a grave > > limitation. Maybe I'm missing some background here. The version we > > have on emacs-27 does support non-ASCII characters in the format. > > 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? > + /* 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?