In io.c, free_io_buffer only clears ptr and left off, len and capa as they were. Since clear_readconv releases the character buffer through it, READ_CHAR_PENDING() kept reporting pending characters after the buffer had been released. As ...YO4 (Yoshinao Muramatsu)
IO#reopen(io) only flushes the write buffer when the IO is writable, and never unreads the read buffer. The buffer happens to be dropped by the io_seek after dup2, but only when the other stream is readable and seekable, otherwise the IO...YO4 (Yoshinao Muramatsu)
IO#reopen(name) discards the byte buffer but keeps the code converter and the character buffer, so characters left over from the previous stream leak into the reopened one. The code converter itself also has to go, since fptr->encs may h...YO4 (Yoshinao Muramatsu)
IO#reopen(io) relies on flush_before_seek to drop the buffers, but io_unread returns at once when rbuf is empty and therefore never reaches clear_codeconv. With characters pending in cbuf and nothing in rbuf they leak into the reopened s...YO4 (Yoshinao Muramatsu)
Unlike IO#rewind, IO#seek and IO#pos= do not clear the character buffer. As io_unread returns at once when rbuf is empty, an ungotten character survives the repositioning while it does not in binary mode. Clear the read converter after r...YO4 (Yoshinao Muramatsu)
While testing my changes on the Windows platform to use an encoding converter for newline conversion for "r", I discovered a failure in test_reopen. This corresponds to case (3) below. I asked an LLM to investigate similar cases and r...YO4 (Yoshinao Muramatsu)
This may overlap with the discussion in ruby/spec, but I'll share my understanding of the current situation with CRuby. The following illustrates the read model for IO in CRuby's implementation. ``` device -> [rbuf] -> encoding conv...YO4 (Yoshinao Muramatsu)
I haven't heard anything. There was no response to the PR either, but if I can point out one thing, I think the CI failure was accidental. I may be overthinking this, but by limiting the scope of this issue too much, we might be miss...YO4 (Yoshinao Muramatsu)