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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: handa <handa <at> gnu.org>
Cc: gregory <at> heytings.org, 46933 <at> debbugs.gnu.org
Subject: bug#46933: Possible bugs in filepos-to-bufferpos / bufferpos-to-filepos
Date: Thu, 01 Apr 2021 18:32:45 +0300

> From: handa <handa <at> gnu.org>
> Cc: gregory <at> heytings.org, 46933 <at> debbugs.gnu.org
> Date: Fri, 02 Apr 2021 00:14:02 +0900
> 
> In article <83tuovmivc.fsf <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > > 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?
> 
> Yes, but one can add them by coding-system-put.

Leaving the :pre-write/:post-read-conversion use case aside, do we
have some means of find where ISO-2022 shift-in/out sequence begins
and ends, so that we never try to decode a partial sequence (and
produce "characters" that are not really in the original buffer)?
If not, where can I find the description of every kind of such
sequences, i.e. sequences that modify the decoder state without
producing any characters?

(UTF-8 has the same issue, btw, but in that case we have a simpler
solution.)

Previous Next

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