Code-generation judge rejects valid solutions using sys.stdin.buffer.readline() or sys.stdout.buffer #160

Problem

The standard-I/O mocks in lcb_runner/evaluation/testing_util.py do not fully support Python binary I/O:

• MockBuffer.readline() always returns the first input line instead of advancing to the next line.
• Capturing replaces sys.stdout with StringIO, which has no .buffer attribute. Consequently, sys.stdout.buffer.write(...) raises AttributeError.

Source: https://github.com/LiveCodeBench/LiveCodeBench/blob/28fef95ea8c9f7a547c8329f2cd3d32b92c1fa24/lcb_runner/evaluation/testing_util.py

Minimal reproductions

mock = MockStdinWithBuffer("1\n2\n")
assert mock.buffer.readline() == b"1\n"
assert mock.buffer.readline() == b"2\n"  # Actually returns b"1\n"

with Capturing():
    sys.stdout.buffer.write(b"hello\n")
# AttributeError: '_io.StringIO' object has no attribute 'buffer'

Impact observed with real benchmark results

I checked the current official main branch (commit 28fef95ea8c9f7a547c8329f2cd3d32b92c1fa24). Using its unmodified run_test, I rejudged the same extracted solutions and test cases from a full 175-problem LiveCodeBench v6 run.

Four solutions that passed with a binary-I/O-capable judge failed with the official judge:

As a control, changing only the stdin mock to a cursor-backed byte stream made abc391_f pass. Changing only stdout capture to support .buffer made the other three solutions pass. The generated solutions and test cases were otherwise unchanged.

For example, abc391_f received this input:

2 5
1 2
3 4
5 6

The expected output is 31, but the official judge obtained 24 because the solution repeatedly read the first line.

Expected behavior

Consecutive sys.stdin.buffer.readline() calls should consume consecutive lines, and bytes written to sys.stdout.buffer should be captured and compared as program output. Text and binary input methods should share a consistent input position.