Subject: Re: bug#10627: char-ready? is broken for multibyte encodings

From: Daniel Hartwig <[email-masked]>
Date: Mon, 25 Feb 2013 09:23:45 +0800

On 25 February 2013 08:06, Mark H Weaver <[email-masked]> wrote:
> Andy Wingo <[email-masked]> writes:
>
>> On Sun 24 Feb 2013 21:14, Mark H Weaver <[email-masked]> writes:
>>
>>> Maybe I'm missing something, but I don't see any semantic problem here,
>>> and it seems straightforward to implement.  'char-ready?' should simply
>>> read bytes until either a complete character is available, or no more
>>> bytes are ready.  In either case, all the bytes should then be 'unget'
>>> before returning.  What's the problem?
>>
>> The problem is that char-ready? should not read anything.
>
> Okay, but if all bytes read are later *unread*, and the reads never
> block, then why does it matter?

Taking care to still use sf_input_waiting for soft ports?  Reading
bytes from a soft port could have side effects (i.e. logging action or
similar).