[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#20783: 25.0.50; [PATCH] byte-to-position has internal off-by-one bug
From: |
Eli Zaretskii |
Subject: |
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@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.