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

Previous Next

Full log

Message #29 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: Sun, 28 Mar 2021 17:51:35 +0300

> From: handa <handa <at> gnu.org>
> Cc: gregory <at> heytings.org, 46933 <at> debbugs.gnu.org
> Date: Sun, 28 Mar 2021 23:29:41 +0900
> 
> > 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.
> 
> Then, that implementation should be changed.
> 
> Any coding system can have :post-read-conversion and
> :pre-write-conversion functions, it is not guaranteed that encoded byte
> length is greater than the number of characters.

Agreed, but AFAICT, ISO-2022-JP doesn't have any of these attributes,
right?

Previous Next

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