Opened 8 years ago

Last modified 5 years ago

#1339 new defect

char-ready? returns #f even when input is available

Reported by: Kooda Owned by:
Priority: minor Milestone: someday
Component: core libraries Version: 4.11.0
Keywords: Cc:
Estimated difficulty: insane


The current implementation of char-ready? on stdio files returns #f if you have buffering enabled, didn’t consume the whole buffer and no more input is available from the system’s point of view, as it only asks the system via select or poll (see C_char_ready_p and C_check_fd_ready).

I’m afraid there’s no way to do better than this with stdio files, as there is no way of checking the state of the buffer.

The workaround I found was to simply disable buffering altogether, like so:

(set-buffering-mode! (current-input-port) #:none)

This bug probably requires a pretty big rework of ports.

Here is a little program that might show the erroneous behaviour:

(use posix)

(call-with-input-pipe "echo coucou"
  (lambda (p)
    (let loop ((c (read-char p)))
      (unless (eof-object? c)
        (print c)
        (when (char-ready? p) (loop (read-char p)))))))

Change History (3)

comment:1 Changed 7 years ago by sjamaan

Milestone: 5.05.1

Not for 5.0

comment:2 Changed 5 years ago by sjamaan

Milestone: 5.15.2

Getting ready for 5.1, moving tickets which won't make it in to 5.2.

comment:3 Changed 5 years ago by felix winkelmann

Milestone: 5.2someday
Note: See TracTickets for help on using tickets.