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 20:39:06 +0000 Message-ID: References: <83imgkw11q.fsf@gnu.org> <837dx0vysk.fsf@gnu.org> <83tv04uhca.fsf@gnu.org> <83pnarvmm2.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="117744"; 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 22:40:09 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 1jdJtJ-000UWg-Gv for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 25 May 2020 22:40:09 +0200 Original-Received: from localhost ([::1]:49326 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jdJtI-00014u-IM for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 25 May 2020 16:40:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60110) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jdJtC-00014c-8s for bug-gnu-emacs@gnu.org; Mon, 25 May 2020 16:40:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59322) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jdJtB-0000lh-Vs for bug-gnu-emacs@gnu.org; Mon, 25 May 2020 16:40:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jdJtB-0006i4-Qg for bug-gnu-emacs@gnu.org; Mon, 25 May 2020 16:40:01 -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 20:40: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.159043919125770 (code B ref 41520); Mon, 25 May 2020 20:40:01 +0000 Original-Received: (at 41520) by debbugs.gnu.org; 25 May 2020 20:39:51 +0000 Original-Received: from localhost ([127.0.0.1]:42635 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdJt0-0006hZ-IG for submit@debbugs.gnu.org; Mon, 25 May 2020 16:39:50 -0400 Original-Received: from mail-ot1-f51.google.com ([209.85.210.51]:40214) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jdJsz-0006hL-3E for 41520@debbugs.gnu.org; Mon, 25 May 2020 16:39:49 -0400 Original-Received: by mail-ot1-f51.google.com with SMTP id d26so14632610otc.7 for <41520@debbugs.gnu.org>; Mon, 25 May 2020 13:39:49 -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=E3WcupDwekfgKuusSUdIB/dFUf/ckY9ICqbGN5drCQU=; b=pAxjGIOen2Cno88bRDg7d5lnPiF0au8pr9rFhmeN85FKA/4Qtnj00fEQLRPuNcnE/G X2e+bsLI/s1X+Is6usfRX0asOvKUrw3Ij9DfXqYZ5LpUyjhaU7c7W4e/HQ4IBXBmOFpm e65yHoPy5EYlABDVmJe7fwbxX8vNotTWYLKhFXfbq0gPkaP2EtZrdmuk+/IB+8Mvd9Xb 0/DReoKSotdHb27QEGfsRUVXcW3xNgxLU74jyb2j/OwVCdsnx/qPGjyqKZKBDGmmN7G/ QGJpOzUS62c6cjGz9BbJXcCXIdo9mY6q1r7gYyeK7V2QqSQNUem7aY93eLs+XsrZr6Vc mVYw== 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=E3WcupDwekfgKuusSUdIB/dFUf/ckY9ICqbGN5drCQU=; b=n7jixSnjm/X7r6MX05f6yu1/54VaFzLoPJU6ugF1GpL3qD4kLb6Eem43WPKmOmOJLy /z2wNiKpxw/JQg8cM2RFM8BoDC1XziE4K3v6rtY4q2k3DOXnif5DUn0nw5szXqvAMA4w gGWvrpj/SQCuASHq9Tw9YWcKILMh0ghaLvvjkSYDuYAPwWLyGbkdMs20F7KmlTM07wgs HSo6QqsiQ5BNccAQNVWyav2EYD936wXqo5vzPbFO5OlIQMr4zaMnzNlzmHHjn/MFp0Se cD/bZ4mGwbgzCLjbQD+IWm+5hVRch/BNeFXCq5gBrWQ7S3h8UWFJZv3xqdmTMM6vLshr 4Leg== X-Gm-Message-State: AOAM531GDvCMyKr/Ig31JX84umC1bXJW5BPTDIW3apvgpV1SybnKueAt DTIVISIsqzVuQ21Ete9pf4lCuyLI/l/yUrXNtnI= X-Google-Smtp-Source: ABdhPJyoz0k2YvsDEyqFYVrOlAzSvsTzWjk5Q3SZZUiSbfHtqfi+O0JsRHMQU2GaWRki29tn+ySGfL2GnMxYz9BE4HA= X-Received: by 2002:a05:6830:61b:: with SMTP id w27mr20442845oti.154.1590439183297; Mon, 25 May 2020 13:39:43 -0700 (PDT) In-Reply-To: <83pnarvmm2.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:181002 Archived-At: On Mon, May 25, 2020 at 7:30 PM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Mon, 25 May 2020 17:54:01 +0000 > > Cc: stefan@marxist.se, 41520@debbugs.gnu.org > > > > All I'm hoping for, at this point, is a "maybe, show me a patch". > > I don't know what to say, since it sounds like the "appetite comes > with eating". We never talked about PT_POS before. You're correct. Sorry about that. > Is the plan to make any popular position a struct? The plan is to introduce additional struct-valued macros for things like PT/PT_BYTE: #define PT_POS POS (PT, PT_BYTE) In particular, it's not an lvalue. That's important to me, since assigning to PT_POS would be a severe bug. > Like GPT, for example? That's difficult. GPT is, of course, very special. I still think the code is slightly more readable with an additional GPT_POS macro being used where appropriate. There's a particular problem because using GPT very often means modifying it, so maybe GPT_POS should be an lval. > What about BEGV and ZV? BEG, BEGV, ZV, and Z would all have _POS equivalents, and very often using them results in more readable code. > IOW, I don't understand the goal here. There are multiple goals: I think this significantly aids readability, and I think there might still be some minor bugs to catch, and future bugs to avoid. For debug builds only, it might make sense to include the object that the bytepos-charpos relation is valid for, to catch cases where one object's correspondence is used for another object. > I think I did understand when we were talking about accessing characters by buffer positions, and > the bugs related to incorrect usage there, but now it sounds like the plot thickens? I hope that most code will follow a basic structure of being passed a Lisp_Object or two (charpos/marker and object), converting that to a pos_t, handing that to internal APIs, potentially receiving a pos_t back and converting it back to a Lisp_Object, with only a few lines of code deep down the call stacks actually unwrapping the pos_t and manipulating it directly. That means there are a few more cases than accessing buffer text: comparing two positions, for example, walking a buffer or string by incrementing or decrementing them, adding two positions or subtracting them. (It's true that all kinds of crazy experiments would be easier with code that follows this structure, but that's a side effect: the goal really is to increase readability a little in a lot of places.) Take, for example, this code: ch = bidi_fetch_char (cpos += nc, bpos += clen, &disp_pos, &dpp, &bs, bidi_it->w, fwp, &clen, &nc) "nc" and "clen" belong together, and so do cpos and bpos. I find the names don't make that very obvious, and simply reducing the number of arguments bidi_fetch_char takes by two helps a little.