GNU bug report logs - #20783
25.0.50; [PATCH] byte-to-position has internal off-by-one bug

Previous Next

Full log

Message #8 received at 20783 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Wolfgang Jenkner <wjenkner <at> inode.at>
Cc: 20783 <at> debbugs.gnu.org
Subject: Re: bug#20783: 25.0.50;
 [PATCH] byte-to-position has internal off-by-one bug
Date: Wed, 10 Jun 2015 20:17:20 +0300

> From: Wolfgang Jenkner <wjenkner <at> inode.at>
> Date: Wed, 10 Jun 2015 17:13:30 +0200
> 
> Here's a test case for the bug:
> 
> (with-temp-buffer
>   (insert "éé")
>   (let ((i 1) pos res)
>     (while (setq pos (byte-to-position i))
>       (push pos res)
>       (setq i (1+ i)))
>     (nreverse res)))
> 
> => (1 2 2 2 3)
> 
> while the correct result is
> 
> => (1 1 2 2 3)
> 
> I found that this bug had been noticed before in
> 
> http://stackoverflow.com/questions/17588117/emacs-byte-to-position-function-is-not-consistent-with-document
> 
> Here's a patch.  The fix may look a bit clumsy but it's actually meant
> to avoid pessimizing the presumably common case where the initial
> bytepos is at a character boundary.

Wouldn't it be better to handle this use case in Fbyte_to_position?
The BYTE_TO_CHAR macro is called an awful lot in the Emacs innermost
loops, and it's _always_ called with a byte position that's on a
character boundary.  So punishing all that code with even a single
comparison, for the benefit of a use case whose importance is unclear
to me is not necessarily TRT.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.