[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#10627: char-ready? is broken for multibyte encodings
From: |
Daniel Hartwig |
Subject: |
bug#10627: char-ready? is broken for multibyte encodings |
Date: |
Mon, 25 Feb 2013 09:23:45 +0800 |
On 25 February 2013 08:06, Mark H Weaver <address@hidden> wrote:
> Andy Wingo <address@hidden> writes:
>
>> On Sun 24 Feb 2013 21:14, Mark H Weaver <address@hidden> 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).