GNU bug report logs - #46933
Possible bugs in filepos-to-bufferpos / bufferpos-to-filepos

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: handa <handa <at> gnu.org>
Cc: gregory <at> heytings.org, 46933 <at> debbugs.gnu.org
Subject: Re: bug#46933: Possible bugs in filepos-to-bufferpos /
 bufferpos-to-filepos
Date: Sat, 27 Mar 2021 16:54:14 +0300

> From: handa <handa <at> gnu.org>
> Cc: gregory <at> heytings.org, 46933 <at> debbugs.gnu.org
> Date: Sat, 27 Mar 2021 22:23:59 +0900
> 
> How about something like this method:
> 1. Encode the buffer text one line by one until we get a longer byte
> sequence than BYTE.
> 2. Delete the result of enoding the last line above.
> 3. Provided that the above last line has chars C1 C2 ... Cn, 
> encode characters C1...Cn, C1...Cn-1, C1...Cn-2 until we get a shorter
> byte sequence than BYTE.
> 
> The first step may be optimized by encode multiple lines instead of
> single line.

Even if we do optimize, this would be very slow, I think.  And what if
the buffer has no newlines?

In any case, the problem is not with encoding, the problem is with
decoding.  Encoding doesn't have this problem because we always encode
more than enough (we use the value of BYTE as the count of
_characters_ to encode, so for ISO-2022 encoding it is usually much
more than needed).  By contrast, when decoding, we decode exactly
BYTE+1 bytes, which then hits the problem if that offset is inside a
shift sequence.

Previous Next

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