Bug #21687: IO＃pos goes wrong after EOF character(ctrl-z) met.

• Status: Open
• Assignee: -
• Target version: -
• ruby -v: ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [x64-mingw-ucrt]
• Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN

[YO4 (Yoshinao Muramatsu)]

In Windows environment, when opening a file with the "r", encountering an EOF character (Ctrl-Z, "\x1A") during reading causes the IO to report END-OF-FILE.

require 'tempfile'

Tempfile.open do |f|
  str = "0123456789\x1A"
  f.write(str + "x"*(1024_0 - str.bytesize))
  f.rewind
  p f.readline.size # => 10
  p f.pos           # => 8191, shuld be 10 but equals rbuf size
end

When the file reaches its end, the file position moves to the position after the last character.
Therefore, when encountering the EOF character, the file position is expected to move to the position of the EOF character.

This is somewhat unrelated, but I understand that self.seek(0, File::SEEK_END) not positioning at the EOF character is a known limitation.

[YO4 (Yoshinao Muramatsu)]

Here is additional issue.
When an intermediate EOF character met, reading operation reports EOF but sometimes IO#eof? does not.

require 'tempfile'

Tempfile.open do |f|
  str = "0123456789\x1A"
  f.write(str + "x"*(1024_0 - str.bytesize))
  f.rewind
  p f.readline # => "0123456789"
  p f.getbyte  # => nil (EOF met)
  p f.eof?     # => false (not EOF met, wrong)
end

In contrast, when the end of the file fits within the read buffer, IO#eof? returns the correct result. This suggests that it recognizes the end of the file rather than an EOF character.

Tempfile.open do |f|
  str = "0123456789\x1A"
  f.write(str + "x"*(1024 - str.bytesize))
  f.rewind
  p f.readline # => "0123456789"
  p f.getbyte  # => nil (EOF met)
  p f.eof?     # => true (EOF met, pseudo good probably)
end

This seems to related to #21634-2

[YO4 (Yoshinao Muramatsu)]

I made PR #15216 for main issue.

After some investigation, it appears the case with #note-1 is mainly related to the behavior of eof(), so it seems appropriate to address it in #21634.