GNU bug report logs - #10627
char-ready? is broken for multibyte encodings

Previous Next

Full log

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

From: Andy Wingo <wingo <at> pobox.com>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 10627 <at> debbugs.gnu.org
Subject: Re: bug#10627: char-ready? is broken for multibyte encodings
Date: Sun, 24 Feb 2013 23:15:33 +0100

Hi :)

On Sun 24 Feb 2013 21:14, Mark H Weaver <mhw <at> netris.org> writes:

> Andy Wingo <wingo <at> pobox.com> writes:
>
>> On Sat 28 Jan 2012 11:21, Mark H Weaver <mhw <at> netris.org> writes:
>>
>>> The R5RS specifies that if 'char-ready?' returns #t, then the next
>>> 'read-char' operation is guaranteed not to hang.  This is not currently
>>> the case for ports using a multibyte encoding.
>>>
>>> 'char-ready?' currently returns #t whenever at least one _byte_ is
>>> available.  This is not correct in general.  It should return #t only if
>>> there is a complete _character_ available.
>>
>> This procedure is omitted in the R6RS because it is not a good
>> interface.  Besides its semantic difficulties, can you think of a sane
>> implementation for multibyte characters?
>
> 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.  If you want
to peek, use peek-char.  Note that if the stream is at EOF, char-ready?
should return #t.

Andy
-- 
http://wingolog.org/

Previous Next

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