8000 [3.12] gh-95782: Fix io.BufferedReader.tell() etc. being able to return offsets < 0 (GH-99709) by miss-islington · Pull Request #115599 · python/cpython · GitHub
[go: up one dir, main page]

Skip to content
< 8000 h1 class="gh-header-title mb-2 lh-condensed f1 mr-0 flex-auto wb-break-word"> [3.12] gh-95782: Fix io.BufferedReader.tell() etc. being able to return offsets < 0 (GH-99709) #115599
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Feb 17, 2024

Conversation

miss-islington
Copy link
Contributor
@miss-islington miss-islington commented Feb 17, 2024

lseek() always returns 0 for character pseudo-devices like
/dev/urandom (for other non-regular files, e.g. /dev/stdin, it
always returns -1, to which CPython reacts by raising appropriate
exceptions). They are thus technically seekable despite not having seek
semantics.

When calling read() on e.g. an instance of io.BufferedReader that
wraps such a file, BufferedReader reads ahead, filling its buffer,
creating a discrepancy between the number of bytes read and the internal
tell() always returning 0, which previously resulted in e.g.
BufferedReader.tell() or BufferedReader.seek() being able to return
positions < 0 even though these are supposed to be always >= 0.

Invariably keep the return value non-negative by returning
max(former_return_value, 0) instead, and add some corresponding tests.
(cherry picked from commit 26800cf)

Co-authored-by: 6t8k 58048945+6t8k@users.noreply.github.com

…n offsets < 0 (pythonGH-99709)

lseek() always returns 0 for character pseudo-devices like
`/dev/urandom` (for other non-regular files, e.g. `/dev/stdin`, it
always returns -1, to which CPython reacts by raising appropriate
exceptions). They are thus technically seekable despite not having seek
semantics.

When calling read() on e.g. an instance of `io.BufferedReader` that
wraps such a file, `BufferedReader` reads ahead, filling its buffer,
creating a discrepancy between the number of bytes read and the internal
`tell()` always returning 0, which previously resulted in e.g.
`BufferedReader.tell()` or `BufferedReader.seek()` being able to return
positions < 0 even though these are supposed to be always >= 0.

Invariably keep the return value non-negative by returning
max(former_return_value, 0) instead, and add some corresponding tests.
(cherry picked from commit 26800cf)

Co-authored-by: 6t8k <58048945+6t8k@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0