bug#26058: utf16->string and utf32->string don't conform to R6RS

[Andy Wingo <wingo@pobox.com>]

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

> Andy Wingo <wingo@pobox.com> writes:
>
>> On Mon 13 Mar 2017 19:10, taylanbayirli@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