classification
Title: Update os.pread to accept the length type as size_t
Type: Stage: resolved
Components: Library (Lib) Versions: Python 3.9
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: corona10, serhiy.storchaka, vstinner
Priority: normal Keywords: patch

Created on 2019-09-24 18:14 by corona10, last changed 2019-09-25 11:53 by serhiy.storchaka. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 16359 merged corona10, 2019-09-24 20:21
Messages (11)
msg353107 - (view) Author: Dong-hee Na (corona10) * (Python triager) Date: 2019-09-24 18:14
I've found this comments.
// TODO length should be size_t!  but Python doesn't support parsing size_t yet.
(https://github.com/python/cpython/blob/279f44678c8b84a183f9eeb85e0b086228154497/Modules/posixmodule.c#L8830)


I don't know when this comment was created.
But at this point, it seems to provide that functionality.
It can be simply solved through the clinic.

How about updating this argument to be size_t and remove the TODO comment?
msg353108 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2019-09-24 18:29
Length should be Py_ssize_t. Python does not support creating bytes objects larger than PY_SSIZE_T_MAX.
msg353109 - (view) Author: Dong-hee Na (corona10) * (Python triager) Date: 2019-09-24 18:38
Oh okay!
Thanks for letting me know.
Is it okay to switch it into Py_ssize_t?
msg353110 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2019-09-24 18:42
I think it is okay. Just check that all platforms which support pread() (Linux, *BSD, macOS) pass the length as size_t instead of int. Windows does not always support length larger than 2 KiB, but it does not support pread() either.
msg353111 - (view) Author: Dong-hee Na (corona10) * (Python triager) Date: 2019-09-24 18:56
Linux: http://man7.org/linux/man-pages/man2/pread.2.html
BSD: https://www.freebsd.org/cgi/man.cgi?pread(2)
macOS: https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/pread.2.html

All of them pass the length as size_t instead of int.
I will send the PR soon :)
msg353143 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2019-09-25 05:47
New changeset ad7736faf5b82a24374c601a72599adf29951080 by Serhiy Storchaka (Dong-hee Na) in branch 'master':
bpo-38265: Update os.pread to accept the length type as Py_ssize_t. (GH-16359)
https://github.com/python/cpython/commit/ad7736faf5b82a24374c601a72599adf29951080
msg353144 - (view) Author: Dong-hee Na (corona10) * (Python triager) Date: 2019-09-25 05:53
Thank you @serhiy.storchaka and Kyle Stanley for the code review and approve.

This issue is now solved.
I close this issue.
msg353166 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-09-25 10:33
Python 3.7 and 3.8 also have os.pread(). Why not also fixing these branches?

--

os.pwrite() uses Py_buffer for its argument and supports size_t size.

os.preadv() and os.pwritev() use internally the C structure "struct iovec" which uses size_t for its iov_len field.
msg353172 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2019-09-25 11:08
Because this looks rather as a new feature than a bug fix. We don't add new features in maintained versions.

Always there is a risk of introducing a regression. We don't know what bugs are contained in 64-bit size support on different platforms. I would not be surprised if for example some old macOS versions accept size_t, but work correctly only with the 32-bit size.
msg353174 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-09-25 11:14
> Because this looks rather as a new feature than a bug fix. We don't add new features in maintained versions.

Oh ok. That's fair. I close the issue.

The workaround is to use os.preadv() or other functions which accept size_t.
msg353183 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2019-09-25 11:53
Or call pread() multiple times and concatenate results.
History
Date User Action Args
2019-09-25 11:53:20serhiy.storchakasetmessages: + msg353183
2019-09-25 11:14:19vstinnersetstatus: open -> closed
resolution: fixed
messages: + msg353174
2019-09-25 11:08:21serhiy.storchakasetmessages: + msg353172
2019-09-25 10:33:24vstinnersetstatus: closed -> open
resolution: fixed -> (no value)
messages: + msg353166
2019-09-25 05:53:07corona10setstatus: open -> closed
resolution: fixed
messages: + msg353144

stage: patch review -> resolved
2019-09-25 05:47:07serhiy.storchakasetmessages: + msg353143
2019-09-24 20:21:41corona10setkeywords: + patch
stage: patch review
pull_requests: + pull_request15940
2019-09-24 18:56:04corona10setmessages: + msg353111
2019-09-24 18:42:40serhiy.storchakasetmessages: + msg353110
2019-09-24 18:38:50corona10setmessages: + msg353109
2019-09-24 18:29:21serhiy.storchakasetmessages: + msg353108
2019-09-24 18:14:15corona10create