From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 13 11:54:40 2020 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 To: Federico Tedin In-Reply-To: <874ktn2yph.fsf@gmail.com> (message from Federico Tedin on Mon, 13 Apr 2020 17:27:06 +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> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40000 Cc: casouri@gmail.com, 40000@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: -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.