GNU bug report logs - #26058
utf16->string and utf32->string don't conform to R6RS

Previous Next

Full log

View this message in rfc822 format

From: Andy Wingo <wingo <at> pobox.com>
To: taylanbayirli <at> gmail.com (Taylan Ulrich "Bayırlı/Kammer")
Cc: 26058 <at> debbugs.gnu.org
Subject: bug#26058: utf16->string and utf32->string don't conform to R6RS
Date: Tue, 14 Mar 2017 16:44:37 +0100

On Tue 14 Mar 2017 16:03, taylanbayirli <at> gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:

> Andy Wingo <wingo <at> pobox.com> writes:
>
>> On Mon 13 Mar 2017 19:10, taylanbayirli <at> gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:
>>
>>> If I do binary I/O, the following situations are possible:
>>>
>>> 1. I'm guaranteed to get any possible bytes that happen to form a valid
>>>    BOM at the start of the stream as-is in the returned bytevector; the
>>>    binary I/O interface doesn't see such bytes as anything special, as
>>>    it could simply be coincidence that the stream starts with such
>>>    bytes.
>>
>> (1).  But I thought this bug was about using a bytevector as a source
>> and then doing textual I/O on it, no?
>
> I have a feeling we're somehow talking past each other. :-) As far as
> I'm concerned, the bug is just that the procedures don't conform to the
> specification.
>
> It would of course be good if the behavior of these procedures was
> somehow in harmony with the behavior of I/O operations, but I don't see
> any issues arising from adopting the R6RS behavior of the procedures
> utf16->string and utf32->string.  Do you?

Adopting the behavior is more or less fine.  If it can be done while
relying on the existing behavior, that is better than something ad-hoc
in a module.

Andy

Previous Next

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