t5608, t7508: require LONG_IS_64BIT for >4GB tests#2129
Open
spkrka wants to merge 1 commit into
Open
Conversation
The >4GB clone tests in t5608 (tests 5-6) fail on Windows because the server-side pack-objects still uses `unsigned long` for object sizes. On Windows x86_64 (LLP64), `unsigned long` is 32 bits, so pack-objects dies in cast_size_t_to_ulong() when it encounters a 4294967297-byte object: fatal: object too large to read on this platform: 4294967297 is cut off to 1 The streaming/odb/index-pack side was widened to size_t in js/objects-larger-than-4gb-on-windows, but pack-objects was deliberately left as a stop-gap with cast_size_t_to_ulong() at the type boundaries. Until the pack-objects path is also widened, gate these tests on LONG_IS_64BIT so they skip on Windows rather than failing. Similarly, t7508's "status does not re-read unchanged 4 or 8 GiB file" test fails on Windows because ftruncate is implemented via _chsize which takes a `long` parameter, overflowing at 2 GiB. The subsequent git-add and git-diff-index also route through object_info.sizep (unsigned long), which would truncate. Add LONG_IS_64BIT here too. Note: LONG_IS_64BIT is a stop-gap, not the right long-term fix. Once the remaining `unsigned long` code paths (pack-objects, object_info.sizep, and the MSVC ftruncate compat shim) are widened to use size_t, these tests should work on all 64-bit platforms and the LONG_IS_64BIT prerequisite can be dropped. Signed-off-by: Kristofer Karlsson <krka@spotify.com>
spkrka
force-pushed
the
fix-4gb-test-prereqs
branch
from
279b211 to
79334a2
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The >4GB clone tests in t5608 and the large-file status test in t7508
fail on Windows x86_64 where
unsigned longis 32 bits.t5608 (tests 5-6): The server-side pack-objects still uses
unsigned longfor object sizes, socast_size_t_to_ulong()dieswhen it encounters a 4294967297-byte object. The streaming/odb side
was widened to
size_tin js/objects-larger-than-4gb-on-windows, butpack-objects was deliberately left as a stop-gap.
t7508 (test 126):
ftruncateis implemented via_chsizeonMSVC, which takes a
longparameter — overflowing at 2 GiB. Thesubsequent
git add/git diff-indexalso route throughobject_info.sizep(unsigned long), which would truncate.Add
LONG_IS_64BITprerequisite so these tests skip on Windowsuntil the remaining
unsigned long→size_twidening lands.cc: @dscho