Summary
char-ready? must ensure a full codepoint is available
Metadata
- Id: 027dfe530855972a44fdaff57dbf13da99b8a32c
- Trac id:
- Type: defect
- Reporter: felix
- Owner:
- Cc:
- Status: new
- Component: core libraries
- Estimated difficulty: medium
- Resolution:
- Priority: minor
- Milestone:
- Version: 6.0.1pre1
- Changetime: 2026-09-06 18:45:22 UTC
- Created: 2026-09-01 20:59:01 UTC
- Keywords:
Description
Scripture demands that "char-ready?" ensures that reading the next char will not block, but currently we only check for any data being available.
(Note also that u8-ready? and char-ready? are currently identical)
Changes and comments
[2026-09-06 18:36:08 UTC] felix wrote:
A separate port-class method for char-ready? has been added (d34bb822) and the old method handles the u8-ready? case (whether any data is available). The char-ready? and u8-ready? primitives use the separate methods now, if available. The extra slot in the port-class vector is optional to not break user code that creates such things (there shouldn't be).
This is currently not really solved. For TCP and process-ports it would be possible to read as much as possible without blocking to ensure char-ready? succeeds only with a full codepoint, but the latter uses make-input-port, which doesn't provide different u8/char-ready? procedures. We could add the u8-ready method by hand, though, by modifying the class vector.
The current status is that scanning for full codepoints is not done yet.