From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Federico Tedin Newsgroups: gmane.emacs.bugs Subject: bug#40000: 27.0.60; next-single-char-property-change hangs on bad argument Date: Mon, 13 Apr 2020 17:27:06 +0200 Message-ID: <874ktn2yph.fsf@gmail.com> References: <87d08b333i.fsf@gmail.com> <83tv1niira.fsf@gnu.org> <878siz31ta.fsf@gmail.com> <83sgh7ihj2.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="105317"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: casouri@gmail.com, 40000@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 13 17:28:27 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 1jO10c-000RIh-Fj for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 13 Apr 2020 17:28:26 +0200 Original-Received: from localhost ([::1]:45438 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jO10b-0000YB-IR for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 13 Apr 2020 11:28:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54882) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jO10F-0000NM-5P for bug-gnu-emacs@gnu.org; Mon, 13 Apr 2020 11:28:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jO10E-0004Lk-54 for bug-gnu-emacs@gnu.org; Mon, 13 Apr 2020 11:28:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48974) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jO10E-0004Lf-1l for bug-gnu-emacs@gnu.org; Mon, 13 Apr 2020 11:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jO10D-0005pP-Tj for bug-gnu-emacs@gnu.org; Mon, 13 Apr 2020 11:28:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Federico Tedin Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Apr 2020 15:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40000 X-GNU-PR-Package: emacs Original-Received: via spool by 40000-submit@debbugs.gnu.org id=B40000.158679163722349 (code B ref 40000); Mon, 13 Apr 2020 15:28:01 +0000 Original-Received: (at 40000) by debbugs.gnu.org; 13 Apr 2020 15:27:17 +0000 Original-Received: from localhost ([127.0.0.1]:60520 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jO0zV-0005oP-EN for submit@debbugs.gnu.org; Mon, 13 Apr 2020 11:27:17 -0400 Original-Received: from mail-wm1-f45.google.com ([209.85.128.45]:53532) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jO0zT-0005oA-LR for 40000@debbugs.gnu.org; Mon, 13 Apr 2020 11:27:16 -0400 Original-Received: by mail-wm1-f45.google.com with SMTP id d77so9660730wmd.3 for <40000@debbugs.gnu.org>; Mon, 13 Apr 2020 08:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=Yq+w6ezCUcVk0NEO5OFmDQPHyuebcvgJ3z4VuOR2uDg=; b=JGhwDz55+NZTKkvjWWa7Yg4/MpQ/HX1q9R90WjRUbSZsTZ1+ZWOAtorTeH9x4UwjaS 7ii2ZyFbU4YiEk+2yv3uXcb52+TXhIxZjxLLv2W30KwDTsbZwCyno1olbCObR9UY5FE0 czO4Sji0a3UdTbK8hRz6vokUjzIjWExTA9eiG9OakBdO5YjyGYWrSur6DhjIEu4Sjlhu mEm3fPrl8vRMGwc1cvck/As29FyGAm14kGPOBjoNzywA0hhUI2Mlxf5VUT0pujhMErnJ Qrf+Z1R6HSCcl+vQI9xHfX1wJ0Gd0aW9Uz8dGwJiN0R4vchGvVImicycdTdnCexUSAFw cw3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=Yq+w6ezCUcVk0NEO5OFmDQPHyuebcvgJ3z4VuOR2uDg=; b=emF/2zJBxD6Y9Ce6Kz17ABi4US1McNI5B2trOfJPMOwSB9DwrBym/GcsRi1+46/Mqm /MBQIW3K2TUPA3KVE1mHOJtkFiPoNRJ+cQIiXi2RT+1B2GN0H8XDDpFPkT+UcD45xHHK H/21Y4UBPB8ZigkfSptOXhHTstHwwHbryAuUurSIERxQY23dZRDOKSFPrYwfSG2d/QUk WEfZh5v3qpSJy+nb9YYn4k8oija/6DavwLoXL32ftQzDNNi57+q8B6iVCIjN5XXVbY4c ugH8bs7i8cBjSxQhmQbz2BLVHyQbDUCDEeMRXNr9Mf/+3x4n/h0hdYOyhuge2Gr0R+g1 PSNw== X-Gm-Message-State: AGi0Pub6YQ5eJ+aUKwE1SU4Jc5ZpSf4ROrmway/d+37DeDj3tzR0NUp+ kWIlsxVxlx1avbrA2PIqFoXjzqCsY+o= X-Google-Smtp-Source: APiQypKm2iXUcNz0smxrwh0KtS52Rdkm2QCL539rD6nAoFJ6ABL+CVMXQWD2VfW2qcfrFp1wSilaSg== X-Received: by 2002:a1c:7215:: with SMTP id n21mr19915276wmc.145.1586791629577; Mon, 13 Apr 2020 08:27:09 -0700 (PDT) Original-Received: from lead ([2a02:8109:8ac0:2ff0:7077:607d:3f1f:454e]) by smtp.gmail.com with ESMTPSA id z16sm16411255wrl.0.2020.04.13.08.27.08 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 13 Apr 2020 08:27:08 -0700 (PDT) In-Reply-To: <83sgh7ihj2.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 13 Apr 2020 17:31:29 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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:178312 Archived-At: > I think this means you are dealing with "undefined behavior". Since > you want to make it well-defined, the results must be consistent, > where they weren't before. > > Note that the doc string also says this: > > In a string, scan runs to the end of the string, unless LIMIT is non-nil. > In a buffer, if LIMIT is nil or omitted, it runs to (point-max), and the > value cannot exceed that. > > So it's quite clear to me that the value should never be more than the > last valid position, both for strings and for buffers. No doubt, no > one called this function with LIMIT beyond the last valid position, > because that would produce an infloop. So a change that will return > the maximum valid position in this case cannot be > backward-incompatible. I agree that the function should always return equal or smaller than the last valid position. In case of buffers, fixing LIMIT > (point-max) is OK because the function wasn't defined for that case anyways, as you mentioned. However I'm not sure if my patch should fix the case for strings where LIMIT > (length object), since that would mean that the returned value would now be (length object) instead of LIMIT. And calls to this function with these types of values could already exist, since in this case the function did not hang.