From unknown Sun Jun 15 08:57:52 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40000: 27.0.60; next-single-char-property-change hangs on bad argument Resent-From: Yuan Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 09 Mar 2020 15:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 40000 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 40000@debbugs.gnu.org X-Debbugs-Original-To: Bug Report Emacs Received: via spool by submit@debbugs.gnu.org id=B.158376841126320 (code B ref -1); Mon, 09 Mar 2020 15:41:02 +0000 Received: (at submit) by debbugs.gnu.org; 9 Mar 2020 15:40:11 +0000 Received: from localhost ([127.0.0.1]:51353 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jBKVm-0006qP-SW for submit@debbugs.gnu.org; Mon, 09 Mar 2020 11:40:11 -0400 Received: from lists.gnu.org ([209.51.188.17]:59107) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jBKVl-0006qI-Fv for submit@debbugs.gnu.org; Mon, 09 Mar 2020 11:40:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39568) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jBKVj-0002rE-ES for bug-gnu-emacs@gnu.org; Mon, 09 Mar 2020 11:40:09 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, HTML_MESSAGE autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jBKVg-0007zX-JV for bug-gnu-emacs@gnu.org; Mon, 09 Mar 2020 11:40:07 -0400 Received: from mail-qk1-x729.google.com ([2607:f8b0:4864:20::729]:38833) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jBKVg-0007zH-Bk for bug-gnu-emacs@gnu.org; Mon, 09 Mar 2020 11:40:04 -0400 Received: by mail-qk1-x729.google.com with SMTP id h14so3666412qke.5 for ; Mon, 09 Mar 2020 08:40:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=a+1eKkY8hlOIWNs4HKxgZEZ84bwLC7FebH5sh5lwsCk=; b=T1ZMOrZ2hx8/q2tOtzSYA/ajzG8AzUoxWsi8Pt6Va5LjR91M8apOc/cYwzeiEd4BrZ loIwq5gsVAmD2TZhytdr5liFczWu1JGPZBaA3FrBBH/07oeC2Nhod+/jVADtRWihhSRS aS+eEDBCOEUvSQ8VyAZ0xbjjoTh2ovTeI7Ibmx7g4IZMDLFcQiB+khR0yareYT3cOY0/ g5dtdLk447IPy1Z4wmR6csrJgd5AM91j+4pkGR+eEqzzGIn+4DQ4Ws49Noo4WraCtN/w b+rUvWSqNAZUoYlLbUCYYiEBWfDWl1PIUI3GFep7zfaBvU87rUUKaJQEulNCHwvpqeYR sVvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=a+1eKkY8hlOIWNs4HKxgZEZ84bwLC7FebH5sh5lwsCk=; b=JHjb3WP+qTR+I2msGfM4r7ymkwd7Ze5ulbpESAX4E/rAmmI06+wmvX7u9CsN96npOU fOqeQ4NgZO+gwWd79Lx0n/h/ehspvlnk88nhYw3fV3mXBN5Znqs8ZRSM/5BrNBObdYJV vi0ocu22EQT+VDo7FsJbKiP1IOSPDxCWuVaXNwDQSqKyIkD44FHEbRE4w6e001C28uix imW70JAlunmZGun5UboKIBGbEdN3tBbwR3QlFzk+EJIp+cJP1kszcMvZwvrUJ0RCl19V 7W9V+j9Y1GFinwC7GsVOCpMnZmqsgYD1mVf9tCdh7s63S+zE8rmR+L6VKS/bTlx8jSiP KPmw== X-Gm-Message-State: ANhLgQ3m5gEUSwbXXqbalelkhS4tmk1Rz/ITTQiKhGa82dRStcvJlWSf nUTCdIAQIpsbRN4dn/yBGJDpzSWBRlBbkoz/ X-Google-Smtp-Source: ADFU+vsn9wHA//MKftjC1O/8M/TuIP/sDOamebqK3LqqlniZKFsXu5RlaEDWyp0IWDKFrZQ8Krue4g== X-Received: by 2002:ae9:dcc1:: with SMTP id q184mr15202591qkf.480.1583768403002; Mon, 09 Mar 2020 08:40:03 -0700 (PDT) Received: from [192.168.1.5] (c-174-60-229-153.hsd1.pa.comcast.net. [174.60.229.153]) by smtp.gmail.com with ESMTPSA id g9sm9325090qkl.39.2020.03.09.08.40.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2020 08:40:02 -0700 (PDT) From: Yuan Fu Content-Type: multipart/alternative; boundary="Apple-Mail=_F4073758-4BA9-4C69-86EE-2510F46E593E" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Message-Id: Date: Mon, 9 Mar 2020 11:40:01 -0400 X-Mailer: Apple Mail (2.3608.60.0.2.5) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::729 X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --Apple-Mail=_F4073758-4BA9-4C69-86EE-2510F46E593E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 If I pass a LIMIT > point-max to next-single-char-property-change, Emacs = hangs. Of course, I shouldn=E2=80=99t pass such a bad argument, but = next-single-char-property-change should probably error out instead of = hanging in a infinite loop IMHO. Here is the relevant C code: while (true) { position =3D Fnext_char_property_change (position, limit); if (XFIXNAT (position) >=3D XFIXNAT (limit)) { position =3D limit; break; } value =3D Fget_char_property (position, prop, object); if (!EQ (value, initial_value)) break; } If it gets a LIMIT larger than point-max, position can never =3D=3D = limit, so it will loop in the while loop infinitely. I would add a check = in the beginning of the function, to signal an out-of-range error. Or = maybe set limit to poin-max quietly. Other similar functions could have = the same problem, previous-single-char-property-change comes to my mind. Yuan In GNU Emacs 27.0.60 (build 1, x86_64-apple-darwin19.3.0, NS = appkit-1894.30 Version 10.15.3 (Build 19D76)) of 2020-02-25 built on missSilver Repository revision: f27187f963e9e36435b508e29256e048799e0ff2 Repository branch: emacs-27 Windowing system distributor 'Apple', version 10.3.1894 System Description: Mac OS X 10.15.3 Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Configured using: 'configure --with-modules --with-pdumper=3Dyes = --oldincludedir=3D/Applications/Xcode.app/Contents/Developer/Platforms/Mac= OSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/libxml2/' Configured features: RSVG GLIB NOTIFY KQUEUE ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS XIM NS MODULES THREADS PDUMPER LCMS2 Important settings: value of $LC_CTYPE: UTF-8 value of $LANG: en_CN.UTF-8 locale-coding-system: utf-8-unix Major mode: Fundamental Minor modes in effect: tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t buffer-read-only: t line-number-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs text-property-search time-date subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/ns-win ns-win ucs-normalize mule-util term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads kqueue cocoa ns lcms2 multi-tty make-network-process emacs) Memory information: ((conses 16 44008 8151) (symbols 48 5908 1) (strings 32 15290 1605) (string-bytes 1 499152) (vectors 16 9324) (vector-slots 8 119382 11662) (floats 8 19 25) (intervals 56 177 0) (buffers 1000 12)) --Apple-Mail=_F4073758-4BA9-4C69-86EE-2510F46E593E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 If I pass a LIMIT > point-max = to next-single-char-property-change, Emacs hangs. Of course, I = shouldn=E2=80=99t pass such a bad argument, = but next-single-char-property-change should probably error out = instead of hanging in a infinite loop IMHO.

Here is the relevant C code:

while (true)
=  {
=    position =3D Fnext_char_property_change (position, = limit);
=    if (XFIXNAT (position) >=3D XFIXNAT = (limit))
=      {
position =3D = limit;
= break;
=      }

  =  value =3D Fget_char_property (position, prop, = object);
=    if (!EQ (value, initial_value))
  =    break;
=  }

If it = gets a LIMIT larger than point-max, position can never =3D=3D limit, so = it will loop in the while loop infinitely. I would add a check in the = beginning of the function, to signal an out-of-range error. Or maybe set = limit to poin-max quietly. Other similar functions could have the same = problem, previous-single-char-property-change comes to my = mind.

Yuan

In GNU Emacs 27.0.60 (build 1, = x86_64-apple-darwin19.3.0, NS appkit-1894.30 Version 10.15.3 (Build = 19D76))
of 2020-02-25 built on missSilver
Repository revision: = f27187f963e9e36435b508e29256e048799e0ff2
Repository = branch: emacs-27
Windowing system distributor 'Apple', = version 10.3.1894
System Description:  Mac OS X 10.15.3

Recent messages:
For information = about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
'configure --with-modules = --with-pdumper=3Dyes
= --oldincludedir=3D/Applications/Xcode.app/Contents/Developer/Platforms/Mac= OSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/libxml2/'

Configured features:
RSVG GLIB = NOTIFY KQUEUE ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS XIM
NS MODULES THREADS PDUMPER LCMS2

Important settings:
  value of $LC_CTYPE: = UTF-8
  = value of $LANG: en_CN.UTF-8
  locale-coding-system: = utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  = global-eldoc-mode: t
  electric-indent-mode: t
  = mouse-wheel-mode: t
  tool-bar-mode: t
  = menu-bar-mode: t
  file-name-shadow-mode: = t
  = global-font-lock-mode: t
  blink-cursor-mode: t
  = auto-composition-mode: t
  auto-encryption-mode: t
  = auto-compression-mode: t
  buffer-read-only: t
  = line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None = found.

Features:
(shadow sort = mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa = derived epg
epg-config gnus-util rmail rmail-loaddefs = text-property-search time-date
subr-x seq byte-opt gv = bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode = mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr = mail-utils
tooltip eldoc electric uniquify ediff-hook = vc-hooks lisp-float-type
mwheel term/ns-win ns-win = ucs-normalize mule-util term/common-win
tool-bar dnd = fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register = page
tab-bar menu-bar rfn-eshadow isearch timer select = scroll-bar mouse
jit-lock font-lock syntax facemenu = font-core term/tty-colors frame
minibuffer cl-generic cham = georgian utf-8-lang misc-lang vietnamese
tibetan thai = tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic = chinese
composite charscript charprop case-table epa-hook = jka-cmpr-hook help
simple abbrev obarray cl-preloaded = nadvice loaddefs button faces
cus-face macroexp files = text-properties overlay sha1 md5 base64 format
env = code-pages mule custom widget hashtable-print-readable backquote
threads kqueue cocoa ns lcms2 multi-tty make-network-process = emacs)

Memory information:
((conses 16 44008 8151)
(symbols 48 5908 1)
(strings 32 15290 1605)
(string-bytes 1 = 499152)
(vectors 16 9324)
(vector-slots 8 = 119382 11662)
(floats 8 19 25)
(intervals = 56 177 0)
(buffers 1000 12))
= --Apple-Mail=_F4073758-4BA9-4C69-86EE-2510F46E593E-- From unknown Sun Jun 15 08:57:52 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40000: 27.0.60; next-single-char-property-change hangs on bad argument Resent-From: Federico Tedin Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Apr 2020 13:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40000 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Yuan Fu Cc: 40000@debbugs.gnu.org Received: via spool by 40000-submit@debbugs.gnu.org id=B40000.15867859512922 (code B ref 40000); Mon, 13 Apr 2020 13:53:02 +0000 Received: (at 40000) by debbugs.gnu.org; 13 Apr 2020 13:52:31 +0000 Received: from localhost ([127.0.0.1]:59418 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jNzVn-0000l4-Bb for submit@debbugs.gnu.org; Mon, 13 Apr 2020 09:52:31 -0400 Received: from mail-wm1-f46.google.com ([209.85.128.46]:53949) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jNzVl-0000kq-Ij for 40000@debbugs.gnu.org; Mon, 13 Apr 2020 09:52:29 -0400 Received: by mail-wm1-f46.google.com with SMTP id d77so9372647wmd.3 for <40000@debbugs.gnu.org>; Mon, 13 Apr 2020 06:52:29 -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=oWs2Ap2gDDflaREDdfp5H1KyqIbibk8fNnYplF1Uh0Q=; b=Z37LGb70vCiL5VPsUOugz3gFQz+zZR8TxXtw4Ld1XHFPsE2MLhlN/TiFuVUhtwzsJ7 NdukC4UV8quLVbEi2SeixlvegYJzlvvkgMAPkSPwYKQyy3WLwvso6ZOb5eGRYN+2sKY+ HxPp6OfQfCPCppynPq17j2NGUo7xhFpaA9Fg60pMsRAHvd/nj0KWY7y+k6rh0g1TkT8V t9zX2/xZtsIxd0bFqBTbUew57Zkh2uPF+KU5WohCM2CdrXXnTH4hBSC8b1juvwrs82hh pNHNrjodJ3xiPcIkbktl3ShvrALidP1HBxaDVVSspBeOwfIi9JRzf4AwOB2njfa3zwT4 xptw== 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=oWs2Ap2gDDflaREDdfp5H1KyqIbibk8fNnYplF1Uh0Q=; b=C2ETn3creDMYZHnUe66BSsbI4Hm83nu9NSUG58wBu5+/P+GyihMCUEMqDAnSCyUcCq ClpH/QjjUo9ZuPnta0bQQ+gZp82AlDkE+/91PvPqNbhb2RifzB2ktas5B7bVNUUEP0mU aDfQBwy12gNlvoymRsRMlVQ37CuDp6vHaNYY+QqKCH8qdhPWhOKPVDl9Ie0B7wQM7jdK S1tigdEtXRm6XyGZvdo78xWqKUNtZAuYfqrMevrrcA/KGBHoEQtFKQdH8XmNB+jcGcxe AD4Ki3fzF3MS83h84c8YmTeY/btrqEVOIms22zNt4r41PZ/HOUosKpXl4s62tdAy5We3 zXeA== X-Gm-Message-State: AGi0Puat/ZJkObvumAPysqHCuANHauQC8IO8QZBab+W2HUtWoxqKsp9m 4jz1NPLViUCoSPXCWcEnWnPd6R6SuPQ= X-Google-Smtp-Source: APiQypJq+i9YIhxnX+gFtE8qADzz+o7hOx/fCxB5I2L/2O0qqhy98tITfr3zHpelAceu6K2NQWlmNg== X-Received: by 2002:a7b:cb51:: with SMTP id v17mr18353588wmj.164.1586785943277; Mon, 13 Apr 2020 06:52:23 -0700 (PDT) Received: from lead ([2a02:8109:8ac0:2ff0:7077:607d:3f1f:454e]) by smtp.gmail.com with ESMTPSA id h2sm15030719wmf.34.2020.04.13.06.52.22 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 13 Apr 2020 06:52:22 -0700 (PDT) From: Federico Tedin References: Date: Mon, 13 Apr 2020 15:52:17 +0200 In-Reply-To: (Yuan Fu's message of "Mon, 9 Mar 2020 11:40:01 -0400") Message-ID: <87d08b333i.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) --=-=-= Content-Type: text/plain (congratulations on bug #40000! :-) I'm attaching a patch which solves the issue. Now, all the `next-*-property-change' functions return LIMIT when it has been specified and no properties where found up to the buffer's end. On the other hand, the `previous-*-property-change' functions are a bit inconsistent for negative values of LIMIT: (previous-single-char-property-change 2 'test nil -1) -> `args-out-of-range' (previous-single-property-change 2 'test nil -1) -> -1 (previous-char-property-change 2 -1) -> 1 (previous-property-change 2 nil -1) -> -1 For positive values of LIMIT I didn't find any problems. Although a negative value for LIMIT doesn't make any sense, only the documentation for `previous-char-property-change' mentions that "LIMIT is a no-op if it is less than (point-min)". So maybe this behavior could be added to the other 3 functions as well. --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=0001-Prevent-hanging-in-next-single-char-property-change.patch >From 3d82dbc65c26d64f4dbef87e4dd3355eaf093ec0 Mon Sep 17 00:00:00 2001 From: Federico Tedin Date: Mon, 13 Apr 2020 15:30:58 +0200 Subject: [PATCH] Prevent hanging in next-single-char-property-change * src/textprop.c (Fnext_single_char_property_change): Prevent Emacs from hanging when the value of LIMIT is greater than the buffer's end position. (Bug#40000) --- src/textprop.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/textprop.c b/src/textprop.c index 960dba3f8d..146cb2c76b 100644 --- a/src/textprop.c +++ b/src/textprop.c @@ -823,7 +823,7 @@ DEFUN ("next-single-char-property-change", Fnext_single_char_property_change, while (true) { position = Fnext_char_property_change (position, limit); - if (XFIXNAT (position) >= XFIXNAT (limit)) + if (XFIXNAT (position) >= XFIXNAT (limit) || XFIXNAT (position) >= ZV) { position = limit; break; -- 2.17.1 --=-=-=-- From unknown Sun Jun 15 08:57:52 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40000: 27.0.60; next-single-char-property-change hangs on bad argument Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Apr 2020 14:06:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40000 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Federico Tedin Cc: casouri@gmail.com, 40000@debbugs.gnu.org Received: via spool by 40000-submit@debbugs.gnu.org id=B40000.158678671313079 (code B ref 40000); Mon, 13 Apr 2020 14:06:01 +0000 Received: (at 40000) by debbugs.gnu.org; 13 Apr 2020 14:05:13 +0000 Received: from localhost ([127.0.0.1]:60450 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jNzi5-0003Ot-H2 for submit@debbugs.gnu.org; Mon, 13 Apr 2020 10:05:13 -0400 Received: from eggs.gnu.org ([209.51.188.92]:59648) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jNzi3-0003OY-Ud for 40000@debbugs.gnu.org; Mon, 13 Apr 2020 10:05:12 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49154) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jNzhy-0006Ob-JN; Mon, 13 Apr 2020 10:05:06 -0400 Received: from [176.228.60.248] (port=4068 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jNzhx-0003RH-LZ; Mon, 13 Apr 2020 10:05:06 -0400 Date: Mon, 13 Apr 2020 17:04:57 +0300 Message-Id: <83tv1niira.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87d08b333i.fsf@gmail.com> (message from Federico Tedin on Mon, 13 Apr 2020 15:52:17 +0200) References: <87d08b333i.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > From: Federico Tedin > Date: Mon, 13 Apr 2020 15:52:17 +0200 > Cc: 40000@debbugs.gnu.org > > I'm attaching a patch which solves the issue. Now, all the > `next-*-property-change' functions return LIMIT when it has been > specified and no properties where found up to the buffer's end. Doesn't that contradict the documentation? It says: If the property is constant all the way to the end of OBJECT, return the last valid position in OBJECT. Your change means this will no longer be true when LIMIT > EOB. Thanks. From unknown Sun Jun 15 08:57:52 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40000: 27.0.60; next-single-char-property-change hangs on bad argument Resent-From: Federico Tedin Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Apr 2020 14:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40000 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: casouri@gmail.com, 40000@debbugs.gnu.org Received: via spool by 40000-submit@debbugs.gnu.org id=B40000.158678761014621 (code B ref 40000); Mon, 13 Apr 2020 14:21:02 +0000 Received: (at 40000) by debbugs.gnu.org; 13 Apr 2020 14:20:10 +0000 Received: from localhost ([127.0.0.1]:60468 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jNzwY-0003ni-Kd for submit@debbugs.gnu.org; Mon, 13 Apr 2020 10:20:10 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:33548) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jNzwX-0003nR-B4 for 40000@debbugs.gnu.org; Mon, 13 Apr 2020 10:20:09 -0400 Received: by mail-wr1-f68.google.com with SMTP id a25so10330931wrd.0 for <40000@debbugs.gnu.org>; Mon, 13 Apr 2020 07:20:09 -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=J/Eeiebbl3Fb3ZBEKz0auIjhVwQLDZpZxCow0jwaceE=; b=d3Eg/kh8Rz1Ghsp79njyu0IX2pchva4rmy8cJyrr0g/eO3fZl+E9hCuiqWImWDP0Di D90+ORd4Y65ncdpmCIuUtockWkvt1GDimoEaU2L/oEfSfLAzG3tD1eQuHeakLmnhK6Hy YrcChAVBoZ8cX3R1xl+EyiFuVAWgf/k8Qf/skfUMRNMV4hXSaql5m6k76hMBZoj8SVaF ZmN6fMNX9SNnGvwH9v5O2gCdzWAhgCDK6ByczUgrKvXYBmx7+ChQaYzcU0+LKefZmEkp K5l6K936lvzFwVZhc+wN03+kej7Ug3u4XIBvUuG8R3CUs0+QcsDS9qntCRaXJOTmE3Sj QdLQ== 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=J/Eeiebbl3Fb3ZBEKz0auIjhVwQLDZpZxCow0jwaceE=; b=sOeS0kr8w+zWLGKh7tCEBNTUf30FYFXfb2lNEkEJFAJWqeS7TAeJrhtPiFlSlEW+Qt dW38Osa6H8PfzjuLqO5FkJs5uo+URvNO3gNhwfx5/UiASzou57s88P4biQu5GjZZ9mti YrcYN+Q+xRB0pVvXPcwQMOWj85tf2ESlJje/Fji6bosRVoMHrdBJqm5So/ySud19mW8I UG45Fn3MclsNdcwYxQQqGMrs9CkZR/i3TlLIQ0QF4tMdnM/suz0en1F+N2Vr6DBr/gLA DKilQc3DgSD1AbEQse+TZWwQBLLkyKRsRad0wh4xRUs9AvB5wFHlDQUwax0jI82waHPA KOWg== X-Gm-Message-State: AGi0PubyDTIoJmNN+Rm8BfiAhDzw40bVX0RZzDWBiCyRO+5LoqGGQLAE DJeZtd6ZcfapdjS3wj/IgUP5CGctUlc= X-Google-Smtp-Source: APiQypIsMnk6L5enISLWh4ijgpNbLtZO40qhskYrsSuDaC6zz0Y3kg0KojlZdxI0OiUfnvKsQQqu7w== X-Received: by 2002:adf:ed01:: with SMTP id a1mr19277690wro.18.1586787603255; Mon, 13 Apr 2020 07:20:03 -0700 (PDT) Received: from lead ([2a02:8109:8ac0:2ff0:7077:607d:3f1f:454e]) by smtp.gmail.com with ESMTPSA id b11sm15165952wrq.26.2020.04.13.07.20.02 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 13 Apr 2020 07:20:02 -0700 (PDT) From: Federico Tedin References: <87d08b333i.fsf@gmail.com> <83tv1niira.fsf@gnu.org> Date: Mon, 13 Apr 2020 16:20:01 +0200 In-Reply-To: <83tv1niira.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 13 Apr 2020 17:04:57 +0300") Message-ID: <878siz31ta.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) Eli Zaretskii writes: >> From: Federico Tedin >> Date: Mon, 13 Apr 2020 15:52:17 +0200 >> Cc: 40000@debbugs.gnu.org >> >> I'm attaching a patch which solves the issue. Now, all the >> `next-*-property-change' functions return LIMIT when it has been >> specified and no properties where found up to the buffer's end. > > Doesn't that contradict the documentation? It says: > > If the property is constant all the way to the end of OBJECT, return the > last valid position in OBJECT. > > Your change means this will no longer be true when LIMIT > EOB. > > Thanks. Aah OK, I missed that part at the end. But if I evaluate: (next-single-char-property-change 0 'test "hello" 10000) It still returns 10000. Is it possible that "return LIMIT if nothing is found before LIMIT" is meant to take precedence over "return the last valid position in OBJECT"? From unknown Sun Jun 15 08:57:52 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40000: 27.0.60; next-single-char-property-change hangs on bad argument Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Apr 2020 14:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40000 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Federico Tedin Cc: casouri@gmail.com, 40000@debbugs.gnu.org Received: via spool by 40000-submit@debbugs.gnu.org id=B40000.158678830815803 (code B ref 40000); Mon, 13 Apr 2020 14:32:01 +0000 Received: (at 40000) by debbugs.gnu.org; 13 Apr 2020 14:31:48 +0000 Received: from localhost ([127.0.0.1]:60487 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jO07o-00046o-LB for submit@debbugs.gnu.org; Mon, 13 Apr 2020 10:31:48 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34113) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jO07n-00046d-Jv for 40000@debbugs.gnu.org; Mon, 13 Apr 2020 10:31:47 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49396) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jO07g-0002Zf-NB; Mon, 13 Apr 2020 10:31:40 -0400 Received: from [176.228.60.248] (port=1702 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jO07d-0000Yu-WB; Mon, 13 Apr 2020 10:31:40 -0400 Date: Mon, 13 Apr 2020 17:31:29 +0300 Message-Id: <83sgh7ihj2.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <878siz31ta.fsf@gmail.com> (message from Federico Tedin on Mon, 13 Apr 2020 16:20:01 +0200) References: <87d08b333i.fsf@gmail.com> <83tv1niira.fsf@gnu.org> <878siz31ta.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > From: Federico Tedin > Cc: casouri@gmail.com, 40000@debbugs.gnu.org > Date: Mon, 13 Apr 2020 16:20:01 +0200 > > Eli Zaretskii writes: > > > If the property is constant all the way to the end of OBJECT, return the > > last valid position in OBJECT. > > > > Your change means this will no longer be true when LIMIT > EOB. > > > > Thanks. > > Aah OK, I missed that part at the end. But if I evaluate: > > (next-single-char-property-change 0 'test "hello" 10000) > > It still returns 10000. Is it possible that "return LIMIT if nothing is > found before LIMIT" is meant to take precedence over "return the last > valid position in OBJECT"? 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. From unknown Sun Jun 15 08:57:52 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40000: 27.0.60; next-single-char-property-change hangs on bad argument 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 X-GNU-PR-Keywords: To: Eli Zaretskii Cc: casouri@gmail.com, 40000@debbugs.gnu.org Received: via spool by 40000-submit@debbugs.gnu.org id=B40000.158679163722349 (code B ref 40000); Mon, 13 Apr 2020 15:28:01 +0000 Received: (at 40000) by debbugs.gnu.org; 13 Apr 2020 15:27:17 +0000 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 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 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) 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) From: Federico Tedin References: <87d08b333i.fsf@gmail.com> <83tv1niira.fsf@gnu.org> <878siz31ta.fsf@gmail.com> <83sgh7ihj2.fsf@gnu.org> Date: Mon, 13 Apr 2020 17:27:06 +0200 In-Reply-To: <83sgh7ihj2.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 13 Apr 2020 17:31:29 +0300") Message-ID: <874ktn2yph.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) > 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. From unknown Sun Jun 15 08:57:52 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40000: 27.0.60; next-single-char-property-change hangs on bad argument Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Apr 2020 15:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40000 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Federico Tedin Cc: casouri@gmail.com, 40000@debbugs.gnu.org Received: via spool by 40000-submit@debbugs.gnu.org id=B40000.158679328025038 (code B ref 40000); Mon, 13 Apr 2020 15:55:01 +0000 Received: (at 40000) by debbugs.gnu.org; 13 Apr 2020 15:54:40 +0000 Received: from localhost ([127.0.0.1]:60537 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jO1Q0-0006Vm-Ia for submit@debbugs.gnu.org; Mon, 13 Apr 2020 11:54:40 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42069) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jO1Py-0006VX-Lw for 40000@debbugs.gnu.org; Mon, 13 Apr 2020 11:54:39 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:50477) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jO1Pt-0008Vs-6C; Mon, 13 Apr 2020 11:54:33 -0400 Received: from [176.228.60.248] (port=2825 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jO1Ps-0001YS-Ka; Mon, 13 Apr 2020 11:54:32 -0400 Date: Mon, 13 Apr 2020 18:54:24 +0300 Message-Id: <83pncbidov.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <874ktn2yph.fsf@gmail.com> (message from Federico Tedin on Mon, 13 Apr 2020 17:27:06 +0200) References: <87d08b333i.fsf@gmail.com> <83tv1niira.fsf@gnu.org> <878siz31ta.fsf@gmail.com> <83sgh7ihj2.fsf@gnu.org> <874ktn2yph.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > From: Federico Tedin > Cc: casouri@gmail.com, 40000@debbugs.gnu.org > Date: Mon, 13 Apr 2020 17:27:06 +0200 > > 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. Then we'd need to clearly document the behavior in each case, I guess. From unknown Sun Jun 15 08:57:52 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40000: 27.0.60; next-single-char-property-change hangs on bad argument Resent-From: Federico Tedin Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 14 Apr 2020 21:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40000 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: casouri@gmail.com, 40000@debbugs.gnu.org Received: via spool by 40000-submit@debbugs.gnu.org id=B40000.158689834621892 (code B ref 40000); Tue, 14 Apr 2020 21:06:02 +0000 Received: (at 40000) by debbugs.gnu.org; 14 Apr 2020 21:05:46 +0000 Received: from localhost ([127.0.0.1]:34896 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jOSkc-0005h2-7b for submit@debbugs.gnu.org; Tue, 14 Apr 2020 17:05:46 -0400 Received: from mail-wr1-f52.google.com ([209.85.221.52]:35899) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jOSka-0005gi-C3 for 40000@debbugs.gnu.org; Tue, 14 Apr 2020 17:05:44 -0400 Received: by mail-wr1-f52.google.com with SMTP id u13so15755260wrp.3 for <40000@debbugs.gnu.org>; Tue, 14 Apr 2020 14:05:44 -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=GloyQzfUzd1/nleBvZboc5e9s8TVapbXNojEPBUlPlM=; b=JmvWess1XPTMExSe0REibtSy1xcTuv98WNRlBxJG0vHL2N5ympxTpyaFBPvIHolTiW j4nBbIngGOe7CzRD0CBJeEPVtO4JX6nxgpovneKIovsa9X+5bNSprU6rlOq3AwqKRGiX Gk8OcWgCcbK6OSGgiG+yhVGfFqKjgYJzmDJ/TOCIgx7VhbMnyh5D2KCEDLqV9JEdSO8o HWDQAFfV85eyFqqdPsf1jux+NGXzGjan89DxA90z9eosxzfKh3+Q/3d9uQPnauNIdc6t Zv4CRrfr6cX6BJ1SNWgSDadHYspMb/YyCZQJzz47qvLwO2LgAm1Gu/e9ZTg4P+HMIDJv D0RA== 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=GloyQzfUzd1/nleBvZboc5e9s8TVapbXNojEPBUlPlM=; b=OoJeoUm8+xlayRx16NZGmhaecWd7DxPeEqfN1/4Y36uAIsMj7NBGkzVpW11OUjeKPe VL1w3apz338A8Dif5USiKYJovmOl5/DpxW+qXqvH8ohXoXgmszhMnmsEltRHTyqdKO75 sno1ZDXtMwXkis1M71f/K0uC0qt1qcyCrdxJjNovzs0q2Am4h6+vNU4U4bZol6SHcW7w O3c9R/PJoJEx5dYcF+uzw9wZCE2poNK0edkdxyFUIDL36nlznhTictOHqNWWTgyrWWug NFc6M/9kg+CPREn2O5QlXGA7vIKcZbIJqH4D8qmhxWHKYFhlePxZ+hpH7wzXQycP55jl 6yog== X-Gm-Message-State: AGi0PuY0f/Y7MKcZUHLHHAHlOyzzs9C6i7hle9cq6EKrpHGmWWGnPJZF tPJo4kf4pj8CmLf9anUErNCYLkCXle0= X-Google-Smtp-Source: APiQypKcPXsQ2h8J9kBr47elXcq382b3TrRcx5Ef+QLciCWO2IxZwhXfWCmzgMLLDvlloTiIHvrFlA== X-Received: by 2002:adf:a704:: with SMTP id c4mr3081580wrd.303.1586898338126; Tue, 14 Apr 2020 14:05:38 -0700 (PDT) Received: from lead ([2a02:8109:8ac0:2ff0:7077:607d:3f1f:454e]) by smtp.gmail.com with ESMTPSA id i129sm20922022wmi.20.2020.04.14.14.05.36 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 14 Apr 2020 14:05:36 -0700 (PDT) From: Federico Tedin References: <87d08b333i.fsf@gmail.com> <83tv1niira.fsf@gnu.org> <878siz31ta.fsf@gmail.com> <83sgh7ihj2.fsf@gnu.org> <874ktn2yph.fsf@gmail.com> <83pncbidov.fsf@gnu.org> Date: Tue, 14 Apr 2020 23:05:35 +0200 In-Reply-To: <83pncbidov.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 13 Apr 2020 18:54:24 +0300") Message-ID: <87v9m1dbhc.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) --=-=-= Content-Type: text/plain > Then we'd need to clearly document the behavior in each case, I guess. Ok, I've taken another shot at it. I updated the function's documentation to reflect what happens with LIMIT when working on a string and on a buffer, hopefully it's clear enough. --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=0001-Prevent-hanging-in-next-single-char-property-change.patch >From 972c1d0f2b479ba9f1ad5643ee9ce5d268077ace Mon Sep 17 00:00:00 2001 From: Federico Tedin Date: Tue, 14 Apr 2020 23:02:44 +0200 Subject: [PATCH] Prevent hanging in next-single-char-property-change * src/textprop.c (Fnext_single_char_property_change): Prevent Emacs from hanging when the value of LIMIT is greater than the buffer's end position. (Bug#40000) --- src/textprop.c | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/src/textprop.c b/src/textprop.c index 960dba3f8d..378c158875 100644 --- a/src/textprop.c +++ b/src/textprop.c @@ -765,15 +765,15 @@ DEFUN ("next-single-char-property-change", Fnext_single_char_property_change, the current buffer), POSITION is a buffer position (integer or marker). If OBJECT is a string, POSITION is a 0-based index into it. -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. -If the optional fourth argument LIMIT is non-nil, don't search -past position LIMIT; return LIMIT if nothing is found before LIMIT. +In a string, scan runs to the end of the string, unless LIMIT is +non-nil, in which case its value is returned if nothing is found +before it. -The property values are compared with `eq'. -If the property is constant all the way to the end of OBJECT, return the -last valid position in OBJECT. */) +In a buffer, if LIMIT is nil or omitted, it runs to (point-max). If +LIMIT is non-nil, scan does not go past it, and the smallest of +(point-max) and LIMIT is returned. + +The property values are compared with `eq'. */) (Lisp_Object position, Lisp_Object prop, Lisp_Object object, Lisp_Object limit) { if (STRINGP (object)) @@ -832,6 +832,12 @@ DEFUN ("next-single-char-property-change", Fnext_single_char_property_change, value = Fget_char_property (position, prop, object); if (!EQ (value, initial_value)) break; + + if (XFIXNAT (position) >= ZV) + { + XSETFASTINT (position, ZV); + break; + } } position = unbind_to (count, position); -- 2.17.1 --=-=-=-- From unknown Sun Jun 15 08:57:52 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40000: 27.0.60; next-single-char-property-change hangs on bad argument Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Apr 2020 12:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40000 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Federico Tedin Cc: casouri@gmail.com, 40000@debbugs.gnu.org Received: via spool by 40000-submit@debbugs.gnu.org id=B40000.158781745026996 (code B ref 40000); Sat, 25 Apr 2020 12:25:01 +0000 Received: (at 40000) by debbugs.gnu.org; 25 Apr 2020 12:24:10 +0000 Received: from localhost ([127.0.0.1]:58980 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSJqs-00071L-5z for submit@debbugs.gnu.org; Sat, 25 Apr 2020 08:24:10 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36948) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSJqq-000716-EW for 40000@debbugs.gnu.org; Sat, 25 Apr 2020 08:24:08 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53828) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSJql-0005pq-5c; Sat, 25 Apr 2020 08:24:03 -0400 Received: from [176.228.60.248] (port=1381 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jSJqj-0000VV-KS; Sat, 25 Apr 2020 08:24:02 -0400 Date: Sat, 25 Apr 2020 15:23:50 +0300 Message-Id: <831rob92jt.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87v9m1dbhc.fsf@gmail.com> (message from Federico Tedin on Tue, 14 Apr 2020 23:05:35 +0200) References: <87d08b333i.fsf@gmail.com> <83tv1niira.fsf@gnu.org> <878siz31ta.fsf@gmail.com> <83sgh7ihj2.fsf@gnu.org> <874ktn2yph.fsf@gmail.com> <83pncbidov.fsf@gnu.org> <87v9m1dbhc.fsf@gmail.com> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Federico Tedin > Cc: casouri@gmail.com, 40000@debbugs.gnu.org > Date: Tue, 14 Apr 2020 23:05:35 +0200 > > > Then we'd need to clearly document the behavior in each case, I guess. > > Ok, I've taken another shot at it. I updated the function's > documentation to reflect what happens with LIMIT when working on a > string and on a buffer, hopefully it's clear enough. Thanks. I have a few minor comments: > Subject: [PATCH] Prevent hanging in next-single-char-property-change > > * src/textprop.c (Fnext_single_char_property_change): Prevent Emacs > from hanging when the value of LIMIT is greater than the buffer's end > position. (Bug#40000) What you used as the description of the change is actually the explanation why the change was made. The description of the change would be something like this: * src/textprop.c (Fnext_single_char_property_change): Clarify in the doc string the behavior when LIMIT is past the end of OBJECT. Stop the search when position gets to end of buffer, for when LIMIT is beyond that. (Bug#40000) The explanation should ideally be in the comments to the code. In this case, I'm not even sure we need an explanation, since there's a reference to the bug report, and the explanation and the fix are quite simple. > -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. > -If the optional fourth argument LIMIT is non-nil, don't search > -past position LIMIT; return LIMIT if nothing is found before LIMIT. > +In a string, scan runs to the end of the string, unless LIMIT is > +non-nil, in which case its value is returned if nothing is found > +before it. > > -The property values are compared with `eq'. > -If the property is constant all the way to the end of OBJECT, return the > -last valid position in OBJECT. */) > +In a buffer, if LIMIT is nil or omitted, it runs to (point-max). If > +LIMIT is non-nil, scan does not go past it, and the smallest of > +(point-max) and LIMIT is returned. > + > +The property values are compared with `eq'. */) Try to avoid passive tense in documentation, it makes the text longer and sometimes harder to understand. Here's how I'd rephrase this: In a string, scan runs to the end of the string, unless LIMIT is non-nil. In a buffer, scan runs to end of buffer, unless LIMIT is non-nil. If the optional fourth argument LIMIT is non-nil, don't search past position LIMIT; return LIMIT if nothing is found before LIMIT. However, if OBJECT is a buffer and LIMIT is beyond the end of the buffer, this function returns `point-max', not LIMIT. The property values are compared with `eq'. > + if (XFIXNAT (position) >= ZV) > + { > + XSETFASTINT (position, ZV); > + break; > + } Here we expect 'position' to have the value of ZV already, right. Then there's no need to use XSETFASTINT; if you want to make sure we never get here with value >= ZV, you can add an assertion. From unknown Sun Jun 15 08:57:52 2025 X-Loop: help-debbugs@gnu.org Subject: bug#40000: 27.0.60; next-single-char-property-change hangs on bad argument Resent-From: Federico Tedin Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 03 May 2020 14:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40000 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: casouri@gmail.com, 40000@debbugs.gnu.org Received: via spool by 40000-submit@debbugs.gnu.org id=B40000.15885147056084 (code B ref 40000); Sun, 03 May 2020 14:06:02 +0000 Received: (at 40000) by debbugs.gnu.org; 3 May 2020 14:05:05 +0000 Received: from localhost ([127.0.0.1]:57501 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVFEu-0001a4-SC for submit@debbugs.gnu.org; Sun, 03 May 2020 10:05:05 -0400 Received: from mail-wr1-f45.google.com ([209.85.221.45]:45889) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVFEp-0001ZR-9j for 40000@debbugs.gnu.org; Sun, 03 May 2020 10:05:03 -0400 Received: by mail-wr1-f45.google.com with SMTP id o27so12396452wra.12 for <40000@debbugs.gnu.org>; Sun, 03 May 2020 07:04:59 -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=EDJHS/LI8+gAL75QJYoIENVGtSXbf5+vu7jLb0sh8nE=; b=Al/LI2OZeoD3QP4O9j2OmwqcG4ZNq+YhhcMNLrG5yMYHQZnLFPyxsm3VoCgCxB3byc D9xN3TgEssf1JK7j/YqgVM6Mmp9x5z0L0QoJAw1pT9332r1FXuykWchj4ovuBHqg/Ds5 6H6fYD9MNSFgS75syNFI70mEE3NchJdRUmJQ74NdMI/1m2dmd/V9qEPgWeGptj+PuiD7 el8fUTEGtpJytgwFUxpkRz8diLmxZ5XTA7pgZBVGWRT2FWzQE/k2FT/kTSVFTilw5x9k M4BP/6XBPoTBJlI84vhymFvR+XLJAx+0ltNA1duPH1tsb6vS5MlfHHBdDGOla+BJM8FK e3gg== 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=EDJHS/LI8+gAL75QJYoIENVGtSXbf5+vu7jLb0sh8nE=; b=jJpE5B+WkfAOSZ+kTF31XJOX8NfZGSYSscQeTfzGAmfkWYhDwiZ6w0NNXqtjKr0lPY lY73aFGmPKRoQBiGYEqOgLRn+VIvGVct7jcnAJR581neQKB/0z0fBKewvebWC0zGnbg2 ZSeF1EBDZMUWwrm7GHdCS4zchv6fLNW7KlM5aVKgFCY2u3wKXXuNc2OXT+ScPIStgK4/ EYxbQ+oCxU6ih9LLShCT0he4c745MP0gcqBHMwFjF2XoILmYSLrEskGgumHnVIBAnSco +AiYspVpd0DbffGFfFK1QP9CZpF/qbXz5ziV85+ALb6An+++hQmppIFzmce3uTfLjDPm 8EeQ== X-Gm-Message-State: AGi0Pua3BUL5+OtMjO0asHAMgf8y5wnCQtgIdhO+ouQ+yGlonEccZe4o cTIY1xfJa6/ztT4wq7AsO2m9uI6kM/k= X-Google-Smtp-Source: APiQypIDzgbS6eyz7gmhmGdvbqHDxcrW4WUdPJwP4oo8YRhREeiOifnrMlzdcKuq8RJZsUAUnzbaUg== X-Received: by 2002:adf:e58d:: with SMTP id l13mr15028155wrm.187.1588514692728; Sun, 03 May 2020 07:04:52 -0700 (PDT) Received: from lead ([2a02:8109:8ac0:2ff0:f846:e136:aa78:2f03]) by smtp.gmail.com with ESMTPSA id h2sm8871807wmf.34.2020.05.03.07.04.51 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Sun, 03 May 2020 07:04:52 -0700 (PDT) From: Federico Tedin References: <87d08b333i.fsf@gmail.com> <83tv1niira.fsf@gnu.org> <878siz31ta.fsf@gmail.com> <83sgh7ihj2.fsf@gnu.org> <874ktn2yph.fsf@gmail.com> <83pncbidov.fsf@gnu.org> <87v9m1dbhc.fsf@gmail.com> <831rob92jt.fsf@gnu.org> Date: Sun, 03 May 2020 16:04:50 +0200 In-Reply-To: <831rob92jt.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 25 Apr 2020 15:23:50 +0300") Message-ID: <877dxtglml.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Hey Eli, thanks for the detailed feedback. > What you used as the description of the change is actually the > explanation why the change was made. The description of the change > would be something like this: > > * src/textprop.c (Fnext_single_char_property_change): Clarify in > the doc string the behavior when LIMIT is past the end of OBJECT. > Stop the search when position gets to end of buffer, for when LIMIT > is beyond that. (Bug#40000) > > The explanation should ideally be in the comments to the code. In > this case, I'm not even sure we need an explanation, since there's a > reference to the bug report, and the explanation and the fix are quite > simple. Aah OK, that makes sense. I agree that the bug number should be enough if someone wants to find an explanation for the changes; I've changed the commit message to the one you proposed. >> -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. >> -If the optional fourth argument LIMIT is non-nil, don't search >> -past position LIMIT; return LIMIT if nothing is found before LIMIT. >> +In a string, scan runs to the end of the string, unless LIMIT is >> +non-nil, in which case its value is returned if nothing is found >> +before it. >> >> -The property values are compared with `eq'. >> -If the property is constant all the way to the end of OBJECT, return the >> -last valid position in OBJECT. */) >> +In a buffer, if LIMIT is nil or omitted, it runs to (point-max). If >> +LIMIT is non-nil, scan does not go past it, and the smallest of >> +(point-max) and LIMIT is returned. >> + >> +The property values are compared with `eq'. */) > > Try to avoid passive tense in documentation, it makes the text longer > and sometimes harder to understand. Here's how I'd rephrase this: > > In a string, scan runs to the end of the string, unless LIMIT is non-nil. > In a buffer, scan runs to end of buffer, unless LIMIT is non-nil. > If the optional fourth argument LIMIT is non-nil, don't search > past position LIMIT; return LIMIT if nothing is found before LIMIT. > However, if OBJECT is a buffer and LIMIT is beyond the end of the > buffer, this function returns `point-max', not LIMIT. Good point, for some reason I am biased towards using the passive tense. I've changed the documentation string. > The property values are compared with `eq'. > >> + if (XFIXNAT (position) >= ZV) >> + { >> + XSETFASTINT (position, ZV); >> + break; >> + } > > Here we expect 'position' to have the value of ZV already, right. > Then there's no need to use XSETFASTINT; if you want to make sure we > never get here with value >= ZV, you can add an assertion. Aah right, because `next-char-property-change' never returns values larger than `point-max'. So in the last iteration, `position' will be `ZV'. I don't feel like it's necessary to add an assertion though, unless the code inside the loop somehow was modified to be longer/more complex. I'm attaching an updated patch. - Fede --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=0001-Prevent-hanging-in-next-single-char-property-change.patch >From 6adaeec2a5681bb290a3a70968952780146abf66 Mon Sep 17 00:00:00 2001 From: Federico Tedin Date: Sun, 3 May 2020 15:47:56 +0200 Subject: [PATCH] Prevent hanging in next-single-char-property-change * src/textprop.c (Fnext_single_char_property_change): Clarify in the doc string the behavior when LIMIT is past the end of OBJECT. Stop the search when position gets to end of buffer, for when LIMIT is beyond that. (Bug#40000) --- src/textprop.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/src/textprop.c b/src/textprop.c index 960dba3f8d..0876badc87 100644 --- a/src/textprop.c +++ b/src/textprop.c @@ -766,14 +766,13 @@ DEFUN ("next-single-char-property-change", Fnext_single_char_property_change, If OBJECT is a string, POSITION is a 0-based index into it. 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. +In a buffer, scan runs to end of buffer, unless LIMIT is non-nil. If the optional fourth argument LIMIT is non-nil, don't search past position LIMIT; return LIMIT if nothing is found before LIMIT. +However, if OBJECT is a buffer and LIMIT is beyond the end of the +buffer, this function returns `point-max', not LIMIT. -The property values are compared with `eq'. -If the property is constant all the way to the end of OBJECT, return the -last valid position in OBJECT. */) +The property values are compared with `eq'. */) (Lisp_Object position, Lisp_Object prop, Lisp_Object object, Lisp_Object limit) { if (STRINGP (object)) @@ -832,6 +831,9 @@ DEFUN ("next-single-char-property-change", Fnext_single_char_property_change, value = Fget_char_property (position, prop, object); if (!EQ (value, initial_value)) break; + + if (XFIXNAT (position) >= ZV) + break; } position = unbind_to (count, position); -- 2.17.1 --=-=-=-- From unknown Sun Jun 15 08:57:52 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Yuan Fu Subject: bug#40000: closed (Re: bug#40000: 27.0.60; next-single-char-property-change hangs on bad argument) Message-ID: References: <83d07dh8hf.fsf@gnu.org> X-Gnu-PR-Message: they-closed 40000 X-Gnu-PR-Package: emacs Reply-To: 40000@debbugs.gnu.org Date: Sat, 09 May 2020 07:30:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1589009402-32746-1" This is a multi-part message in MIME format... ------------=_1589009402-32746-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #40000: 27.0.60; next-single-char-property-change hangs on bad argument which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 40000@debbugs.gnu.org. --=20 40000: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D40000 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1589009402-32746-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 40000-done) by debbugs.gnu.org; 9 May 2020 07:29:34 +0000 Received: from localhost ([127.0.0.1]:46730 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXJvS-0008Uo-72 for submit@debbugs.gnu.org; Sat, 09 May 2020 03:29:34 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33294) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXJvQ-0008Ub-V3 for 40000-done@debbugs.gnu.org; Sat, 09 May 2020 03:29:33 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46468) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXJvL-0001Lt-NI; Sat, 09 May 2020 03:29:27 -0400 Received: from [176.228.60.248] (port=4161 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jXJvL-0005Yb-2b; Sat, 09 May 2020 03:29:27 -0400 Date: Sat, 09 May 2020 10:29:16 +0300 Message-Id: <83d07dh8hf.fsf@gnu.org> From: Eli Zaretskii To: Federico Tedin In-Reply-To: <877dxtglml.fsf@gmail.com> (message from Federico Tedin on Sun, 03 May 2020 16:04:50 +0200) Subject: Re: bug#40000: 27.0.60; next-single-char-property-change hangs on bad argument References: <87d08b333i.fsf@gmail.com> <83tv1niira.fsf@gnu.org> <878siz31ta.fsf@gmail.com> <83sgh7ihj2.fsf@gnu.org> <874ktn2yph.fsf@gmail.com> <83pncbidov.fsf@gnu.org> <87v9m1dbhc.fsf@gmail.com> <831rob92jt.fsf@gnu.org> <877dxtglml.fsf@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 40000-done Cc: casouri@gmail.com, 40000-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Federico Tedin > Cc: casouri@gmail.com, 40000@debbugs.gnu.org > Date: Sun, 03 May 2020 16:04:50 +0200 > > I'm attaching an updated patch. Thanks, pushed to the master branch, and closing the bug. ------------=_1589009402-32746-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 9 Mar 2020 15:40:11 +0000 Received: from localhost ([127.0.0.1]:51353 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jBKVm-0006qP-SW for submit@debbugs.gnu.org; Mon, 09 Mar 2020 11:40:11 -0400 Received: from lists.gnu.org ([209.51.188.17]:59107) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jBKVl-0006qI-Fv for submit@debbugs.gnu.org; Mon, 09 Mar 2020 11:40:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39568) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jBKVj-0002rE-ES for bug-gnu-emacs@gnu.org; Mon, 09 Mar 2020 11:40:09 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, HTML_MESSAGE autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jBKVg-0007zX-JV for bug-gnu-emacs@gnu.org; Mon, 09 Mar 2020 11:40:07 -0400 Received: from mail-qk1-x729.google.com ([2607:f8b0:4864:20::729]:38833) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jBKVg-0007zH-Bk for bug-gnu-emacs@gnu.org; Mon, 09 Mar 2020 11:40:04 -0400 Received: by mail-qk1-x729.google.com with SMTP id h14so3666412qke.5 for ; Mon, 09 Mar 2020 08:40:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=a+1eKkY8hlOIWNs4HKxgZEZ84bwLC7FebH5sh5lwsCk=; b=T1ZMOrZ2hx8/q2tOtzSYA/ajzG8AzUoxWsi8Pt6Va5LjR91M8apOc/cYwzeiEd4BrZ loIwq5gsVAmD2TZhytdr5liFczWu1JGPZBaA3FrBBH/07oeC2Nhod+/jVADtRWihhSRS aS+eEDBCOEUvSQ8VyAZ0xbjjoTh2ovTeI7Ibmx7g4IZMDLFcQiB+khR0yareYT3cOY0/ g5dtdLk447IPy1Z4wmR6csrJgd5AM91j+4pkGR+eEqzzGIn+4DQ4Ws49Noo4WraCtN/w b+rUvWSqNAZUoYlLbUCYYiEBWfDWl1PIUI3GFep7zfaBvU87rUUKaJQEulNCHwvpqeYR sVvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=a+1eKkY8hlOIWNs4HKxgZEZ84bwLC7FebH5sh5lwsCk=; b=JHjb3WP+qTR+I2msGfM4r7ymkwd7Ze5ulbpESAX4E/rAmmI06+wmvX7u9CsN96npOU fOqeQ4NgZO+gwWd79Lx0n/h/ehspvlnk88nhYw3fV3mXBN5Znqs8ZRSM/5BrNBObdYJV vi0ocu22EQT+VDo7FsJbKiP1IOSPDxCWuVaXNwDQSqKyIkD44FHEbRE4w6e001C28uix imW70JAlunmZGun5UboKIBGbEdN3tBbwR3QlFzk+EJIp+cJP1kszcMvZwvrUJ0RCl19V 7W9V+j9Y1GFinwC7GsVOCpMnZmqsgYD1mVf9tCdh7s63S+zE8rmR+L6VKS/bTlx8jSiP KPmw== X-Gm-Message-State: ANhLgQ3m5gEUSwbXXqbalelkhS4tmk1Rz/ITTQiKhGa82dRStcvJlWSf nUTCdIAQIpsbRN4dn/yBGJDpzSWBRlBbkoz/ X-Google-Smtp-Source: ADFU+vsn9wHA//MKftjC1O/8M/TuIP/sDOamebqK3LqqlniZKFsXu5RlaEDWyp0IWDKFrZQ8Krue4g== X-Received: by 2002:ae9:dcc1:: with SMTP id q184mr15202591qkf.480.1583768403002; Mon, 09 Mar 2020 08:40:03 -0700 (PDT) Received: from [192.168.1.5] (c-174-60-229-153.hsd1.pa.comcast.net. [174.60.229.153]) by smtp.gmail.com with ESMTPSA id g9sm9325090qkl.39.2020.03.09.08.40.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2020 08:40:02 -0700 (PDT) From: Yuan Fu Content-Type: multipart/alternative; boundary="Apple-Mail=_F4073758-4BA9-4C69-86EE-2510F46E593E" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: 27.0.60; next-single-char-property-change hangs on bad argument Message-Id: Date: Mon, 9 Mar 2020 11:40:01 -0400 To: Bug Report Emacs X-Mailer: Apple Mail (2.3608.60.0.2.5) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::729 X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --Apple-Mail=_F4073758-4BA9-4C69-86EE-2510F46E593E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 If I pass a LIMIT > point-max to next-single-char-property-change, Emacs = hangs. Of course, I shouldn=E2=80=99t pass such a bad argument, but = next-single-char-property-change should probably error out instead of = hanging in a infinite loop IMHO. Here is the relevant C code: while (true) { position =3D Fnext_char_property_change (position, limit); if (XFIXNAT (position) >=3D XFIXNAT (limit)) { position =3D limit; break; } value =3D Fget_char_property (position, prop, object); if (!EQ (value, initial_value)) break; } If it gets a LIMIT larger than point-max, position can never =3D=3D = limit, so it will loop in the while loop infinitely. I would add a check = in the beginning of the function, to signal an out-of-range error. Or = maybe set limit to poin-max quietly. Other similar functions could have = the same problem, previous-single-char-property-change comes to my mind. Yuan In GNU Emacs 27.0.60 (build 1, x86_64-apple-darwin19.3.0, NS = appkit-1894.30 Version 10.15.3 (Build 19D76)) of 2020-02-25 built on missSilver Repository revision: f27187f963e9e36435b508e29256e048799e0ff2 Repository branch: emacs-27 Windowing system distributor 'Apple', version 10.3.1894 System Description: Mac OS X 10.15.3 Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Configured using: 'configure --with-modules --with-pdumper=3Dyes = --oldincludedir=3D/Applications/Xcode.app/Contents/Developer/Platforms/Mac= OSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/libxml2/' Configured features: RSVG GLIB NOTIFY KQUEUE ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS XIM NS MODULES THREADS PDUMPER LCMS2 Important settings: value of $LC_CTYPE: UTF-8 value of $LANG: en_CN.UTF-8 locale-coding-system: utf-8-unix Major mode: Fundamental Minor modes in effect: tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t buffer-read-only: t line-number-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs text-property-search time-date subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/ns-win ns-win ucs-normalize mule-util term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads kqueue cocoa ns lcms2 multi-tty make-network-process emacs) Memory information: ((conses 16 44008 8151) (symbols 48 5908 1) (strings 32 15290 1605) (string-bytes 1 499152) (vectors 16 9324) (vector-slots 8 119382 11662) (floats 8 19 25) (intervals 56 177 0) (buffers 1000 12)) --Apple-Mail=_F4073758-4BA9-4C69-86EE-2510F46E593E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 If I pass a LIMIT > point-max = to next-single-char-property-change, Emacs hangs. Of course, I = shouldn=E2=80=99t pass such a bad argument, = but next-single-char-property-change should probably error out = instead of hanging in a infinite loop IMHO.

Here is the relevant C code:

while (true)
=  {
=    position =3D Fnext_char_property_change (position, = limit);
=    if (XFIXNAT (position) >=3D XFIXNAT = (limit))
=      {
position =3D = limit;
= break;
=      }

  =  value =3D Fget_char_property (position, prop, = object);
=    if (!EQ (value, initial_value))
  =    break;
=  }

If it = gets a LIMIT larger than point-max, position can never =3D=3D limit, so = it will loop in the while loop infinitely. I would add a check in the = beginning of the function, to signal an out-of-range error. Or maybe set = limit to poin-max quietly. Other similar functions could have the same = problem, previous-single-char-property-change comes to my = mind.

Yuan

In GNU Emacs 27.0.60 (build 1, = x86_64-apple-darwin19.3.0, NS appkit-1894.30 Version 10.15.3 (Build = 19D76))
of 2020-02-25 built on missSilver
Repository revision: = f27187f963e9e36435b508e29256e048799e0ff2
Repository = branch: emacs-27
Windowing system distributor 'Apple', = version 10.3.1894
System Description:  Mac OS X 10.15.3

Recent messages:
For information = about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
'configure --with-modules = --with-pdumper=3Dyes
= --oldincludedir=3D/Applications/Xcode.app/Contents/Developer/Platforms/Mac= OSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/libxml2/'

Configured features:
RSVG GLIB = NOTIFY KQUEUE ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS XIM
NS MODULES THREADS PDUMPER LCMS2

Important settings:
  value of $LC_CTYPE: = UTF-8
  = value of $LANG: en_CN.UTF-8
  locale-coding-system: = utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  = global-eldoc-mode: t
  electric-indent-mode: t
  = mouse-wheel-mode: t
  tool-bar-mode: t
  = menu-bar-mode: t
  file-name-shadow-mode: = t
  = global-font-lock-mode: t
  blink-cursor-mode: t
  = auto-composition-mode: t
  auto-encryption-mode: t
  = auto-compression-mode: t
  buffer-read-only: t
  = line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None = found.

Features:
(shadow sort = mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa = derived epg
epg-config gnus-util rmail rmail-loaddefs = text-property-search time-date
subr-x seq byte-opt gv = bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode = mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr = mail-utils
tooltip eldoc electric uniquify ediff-hook = vc-hooks lisp-float-type
mwheel term/ns-win ns-win = ucs-normalize mule-util term/common-win
tool-bar dnd = fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register = page
tab-bar menu-bar rfn-eshadow isearch timer select = scroll-bar mouse
jit-lock font-lock syntax facemenu = font-core term/tty-colors frame
minibuffer cl-generic cham = georgian utf-8-lang misc-lang vietnamese
tibetan thai = tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic = chinese
composite charscript charprop case-table epa-hook = jka-cmpr-hook help
simple abbrev obarray cl-preloaded = nadvice loaddefs button faces
cus-face macroexp files = text-properties overlay sha1 md5 base64 format
env = code-pages mule custom widget hashtable-print-readable backquote
threads kqueue cocoa ns lcms2 multi-tty make-network-process = emacs)

Memory information:
((conses 16 44008 8151)
(symbols 48 5908 1)
(strings 32 15290 1605)
(string-bytes 1 = 499152)
(vectors 16 9324)
(vector-slots 8 = 119382 11662)
(floats 8 19 25)
(intervals = 56 177 0)
(buffers 1000 12))
= --Apple-Mail=_F4073758-4BA9-4C69-86EE-2510F46E593E-- ------------=_1589009402-32746-1--