GNU bug report logs - #18520
string ports should not have an encoding

Previous Next

Full log

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: David Kastrup <dak <at> gnu.org>
Cc: 18520 <at> debbugs.gnu.org
Subject: Re: bug#18520: string ports should not have an encoding
Date: Mon, 22 Sep 2014 14:21:21 +0200

I see my reply failed to address some of the points raised.

David Kastrup <dak <at> gnu.org> skribis:

> Guile-2.2 does not consult %default-port-encoding but uses UTF-8
> consistently (I guess, overriding set-port-encoding! will again change
> that).
>
> That still is not satisfactory.  For example, using ftell on the input
> port will not report the string index of the string connected to the
> string port but rather a byte index into a UTF-8 encoded version of the
> string.  This is a number that has nothing to do with the original
> string and cannot be used for correlating string and port.

Right.

> Ports fundamentally deliver characters, and so reading and writing from
> a string source/sink should not involve _any_ coding system.
>
> Files fundamentally deliver bytes, a conversion is required.  The same
> would be the case when opening a port on a _bytevector_.  Here an
> encoding would make equally make sense, and ftell/fseek offsets would
> naturally be in bytes.  But a port on a string delivers and consumes
> characters.  Any conversion, even a fixed UTF-8 conversion, will destroy
> the predictable nature of with-output-to-string and
> with-input-from-string and the respective uses of string ports.

Guile ports can be mixed textual/binary (unlike R6 ports, which are
either textual or binary.)  Thus, they fundamentally deliver bytes,
possibly with a textual conversion.

Although the manual isn’t clear about it, ‘ftell’, when available,
returns a position in bytes.  The situation for string ports here is
comparable to that of other ports used for textual I/O.

Do you have a situation where you were relying on 1.8’s behavior in that
regard?  Could we see whether this can be solved differently?

Thanks,
Ludo’.

Previous Next

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