From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#41520: 28.0.50; Crash in character.h due to assertion error Date: Mon, 25 May 2020 15:16:09 +0000 Message-ID: References: <83imgkw11q.fsf@gnu.org> <837dx0vysk.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="52925"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 41520@debbugs.gnu.org, stefan@marxist.se To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 25 17:19:20 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 1jdEsq-000Dfy-6b for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 25 May 2020 17:19:20 +0200 Original-Received: from localhost ([::1]:32846 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jdEsp-0004H5-6Y for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 25 May 2020 11:19:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55578) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jdEqc-0001dH-Ff for bug-gnu-emacs@gnu.org; Mon, 25 May 2020 11:17:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58850) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jdEqc-0001K7-5d for bug-gnu-emacs@gnu.org; Mon, 25 May 2020 11:17:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jdEqc-00074n-1T for bug-gnu-emacs@gnu.org; Mon, 25 May 2020 11:17:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 25 May 2020 15:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41520 X-GNU-PR-Package: emacs Original-Received: via spool by 41520-submit@debbugs.gnu.org id=B41520.159041981427185 (code B ref 41520); Mon, 25 May 2020 15:17:01 +0000 Original-Received: (at 41520) by debbugs.gnu.org; 25 May 2020 15:16:54 +0000 Original-Received: from localhost ([127.0.0.1]:42163 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdEqT-00074P-NP for submit@debbugs.gnu.org; Mon, 25 May 2020 11:16:53 -0400 Original-Received: from mail-oi1-f182.google.com ([209.85.167.182]:36715) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdEqR-00074B-BK for 41520@debbugs.gnu.org; Mon, 25 May 2020 11:16:51 -0400 Original-Received: by mail-oi1-f182.google.com with SMTP id x23so16279012oic.3 for <41520@debbugs.gnu.org>; Mon, 25 May 2020 08:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JoRkO1kMeO5a78bkb+xR5iRKnG2m6pr2MjwkGMRkseU=; b=b+o0THjkgTiyb0meEC7ulu53VvJ1S0qqR6nN6G81ft0bBXQC8eEifEScDJd48LDZEV wjTgvV7H/3/OT5xNTe3Hh1qU7w7GFJqdWMh6QlEwC02q6oagnF6uJ9tsLU5AarX3YeVP lmVB+t5wkjsdSYrJaLrJLgPpNOcElQTYT/p8BEy3uNsDJvb+XpUv1rPur3R1O8L3yY5M kSOmEsiOlVFse/dqfqo3Nu6CfDuztbvnUA2WiHElxu2va4yzzta5vjsZPgdo6HbvNADm 8oJyy0WT2BGYiIhEbdWVkO3Lg65JwjMVo63rnfG/DR0DSAfxYTc5rChVyThboVlK4tjo 6wNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JoRkO1kMeO5a78bkb+xR5iRKnG2m6pr2MjwkGMRkseU=; b=CwpVKvl0rZde8jpEvWiGs8m3YOTQlx3S0t8USrhShBmJlZGVE9w+T3fzDqb3AthKz/ QxnwRMc2B1QFpVbsh9bJkgxinfOqp3GSXxCUP2QYbyhaZUlPBg/d5yeEScb81g96sfBD m4TgOgKq9gGkOHaxWdaox0hKXwmWBUsPtcneA9eSITnp8W5cJ+ZEkD+lBw4GjaXW6ftQ f0mHg+/bf8wYpCVH3VMYPkz0gKekJILF/dAds8+LTcxoeeESmuSmvegrK4TxcvaCcGDm xeS8R89uAqJgc3fuPauycv6D6qam+pEeKNOk1MICYxApxy9xFT4I8fUIvFxDJkiYK/WG HXug== X-Gm-Message-State: AOAM531OQ8hXMpnVQrqiLYPIqgltlHpdJ1eGOLW7/3LU9+XReNNCiF+4 xP7Ws9VwNbBrLVUtOOhR0ghmZC+I/TYHwCrkdSY= X-Google-Smtp-Source: ABdhPJxaDY2hCNWxjGNWJErLVub2w4QlE5KZHElT62QVJbf7Ma4P+Pm34DcR2Fo/xMMD2xBCnD5ixlcRYdVqEA3mjSo= X-Received: by 2002:aca:b708:: with SMTP id h8mr9839990oif.122.1590419805574; Mon, 25 May 2020 08:16:45 -0700 (PDT) In-Reply-To: <837dx0vysk.fsf@gnu.org> 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:180982 Archived-At: On Mon, May 25, 2020 at 3:07 PM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Mon, 25 May 2020 14:30:55 +0000 > > Cc: stefan@marxist.se, 41520@debbugs.gnu.org > > > > I'm attaching a patch with a few more cases. I don't have a strong > > preference for either FETCH_BYTE or FETCH_CHAR where both will do, but > > we should be consistent. > > I'm okay with those additional changes, but let's install them on > master, as they are a cleanup, not a bug. Sure. > > > That would require us to maintain both character and byte positions > > > where we use these macros, > > > > For now, I'd like to introduce them in Emacs proper only where we have > > pairs of variables anyway. > > Maybe a new macro that accepts a 'struct text_pos'? Yes, a pos_t would look like a struct text_pos, at least in non-debug builds. > But wouldn't it be strange to see a macro that accepts a struct, but > only uses one member of that struct? I don't think so. CHARPOS and BYTEPOS already exist, and that's precisely what they do. What is a little strange is that the ancient convention of not returning struct types is still followed in much of Emacs. > > > Moreover, I think we prefer having assertions in the debug > > > builds rather then silent fixups (and in production eassume compiles > > > into something that doesn't abort). > > > > I see no way to have assertions > > I mean we already have assertions: that's what eassume does in a debug > build. Yes, but we could do with some stricter checking, I think.