From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Third Newsgroups: gmane.emacs.bugs Subject: bug#44349: 28.0.50; Assertion failure on macOS when resizing frame Date: Sat, 28 Nov 2020 22:06:45 +0000 Message-ID: <20201128220645.GF26836@breton.holly.idiocy.org> References: <83eelegxq6.fsf@gnu.org> <83a6w2gwxz.fsf@gnu.org> <20201127222429.GD26836@breton.holly.idiocy.org> <835z5por4y.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28334"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 44349@debbugs.gnu.org, p.stephani2@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Nov 28 23:08:19 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 1kj8OB-00077k-2G for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 28 Nov 2020 23:08:19 +0100 Original-Received: from localhost ([::1]:57968 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kj8O4-00053z-MZ for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 28 Nov 2020 17:08:12 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37242) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kj8Nu-00053W-7c for bug-gnu-emacs@gnu.org; Sat, 28 Nov 2020 17:08:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37739) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kj8Nt-0006kt-W0 for bug-gnu-emacs@gnu.org; Sat, 28 Nov 2020 17:08:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kj8Nt-0005P0-Rd for bug-gnu-emacs@gnu.org; Sat, 28 Nov 2020 17:08:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Third Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 Nov 2020 22:08: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.160660122420660 (code B ref 44349); Sat, 28 Nov 2020 22:08:01 +0000 Original-Received: (at 44349) by debbugs.gnu.org; 28 Nov 2020 22:07:04 +0000 Original-Received: from localhost ([127.0.0.1]:49279 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kj8My-0005N9-Gi for submit@debbugs.gnu.org; Sat, 28 Nov 2020 17:07:04 -0500 Original-Received: from wilbur.contactoffice.com ([212.3.242.68]:52754) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kj8Mv-0005Mf-5c for 44349@debbugs.gnu.org; Sat, 28 Nov 2020 17:07:02 -0500 Original-Received: from smtpauth2.co-bxl (smtpauth2.co-bxl [10.2.0.24]) by wilbur.contactoffice.com (Postfix) with ESMTP id 2F78F98A; Sat, 28 Nov 2020 23:06:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1606601210; s=20200222-6h9o; d=idiocy.org; i=alan@idiocy.org; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:In-Reply-To; l=2254; bh=bPwuGAeFsmQmfNsf0rHmFj/OD2O81h58XapSR2uNFXw=; b=Hf2PaO06ezFOox5iel7WRf/L/QnP3KFxtJsBO5fJKKZEGkZ8i6dL9bH89YRjM1jH WrrHYRlIfDTW3YfL8xbzdBDU9J8l4tbTP3+o3jixCbOH0xRlhoYvr5DKIWIbQxEtaQY 6M//xO/hNBU/YEJd9zbxFg7q8XM5XKJHwUIyuK7rJvZD0xjJhyLoT9HRKMyYqjtf1/X mATHQ03tKTtvwPWA9yZput5ahkhnyMaKu29RUaOsf2uKBY1eneoimYZX4+fkF3x1Xzp YX0zBBp2mou5qtxuZY6CYEvbk2DUeWQwtW8ttcdNKN0dgmBS7UXMvBKQV17CiErxiqF VcVW7VJ7zw== Original-Received: by smtp.mailfence.com with ESMTPA ; Sat, 28 Nov 2020 23:06:47 +0100 (CET) Original-Received: by breton.holly.idiocy.org (Postfix, from userid 501) id ACE3E20269A8BD; Sat, 28 Nov 2020 22:06:45 +0000 (GMT) Mail-Followup-To: Alan Third , Eli Zaretskii , p.stephani2@gmail.com, 44349@debbugs.gnu.org Content-Disposition: inline In-Reply-To: <835z5por4y.fsf@gnu.org> X-ContactOffice-Account: com:241649512 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:194516 Archived-At: 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 > > Cc: Philipp Stephani , 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