fix: reject short fileobj reads - #2887
Conversation
|
@dfgvaetyj3456356-hash Please test this locally. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #2887 +/- ##
=======================================
Coverage 90.39% 90.39%
=======================================
Files 16 16
Lines 2509 2509
=======================================
Hits 2268 2268
Misses 241 241 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Tested locally on Windows with an editable build of this branch against HDF5 1.12.2.\n\nEnvironment:\n- Python 3.11.9\n- h5py 3.16.0 from this checkout\n- HDF5 1.12.2 built locally with Visual Studio 2022 Build Tools\n- NumPy 2.4.6\n- Cython 3.2.5\n\nCommands/results:\n- \pytest h5py/tests/test_file2.py::TestFileObj::test_short_readinto -q\ -> \1 passed\\n- \pytest h5py/tests/test_file2.py::TestFileObj -q\ -> \9 passed, 1 skipped\\n\nAlso confirmed the PR CI/Codecov are green from the GitHub checks. |
Summary
Fixes #2835.
The
fileobjVFD read callback now treats short reads as failures for both file-like read paths:readinto()before returning success-1for shortread()results, matchingherr_tfailure conventionsPreviously,
readinto()results were ignored, so a file-like object that returned fewer bytes than requested could leave part of the destination buffer untouched while the callback still returned success. The fallbackread()path also returned1for a short read, which is non-negative and therefore not a conventionalherr_tfailure.Tests
Added
TestFileObj.test_short_readinto, which builds a valid in-memory HDF5 file and then serves it through a file-like object whosereadinto()intentionally returns one byte short.Local checks run:
python -m py_compile h5py\tests\test_file2.pygit diff --checkI could not run the new runtime test locally in this checkout because Cython is not installed here, and this change touches a Cython template that needs the normal h5py extension build.