You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add 32-bit expectations for remaining == size assertions
Most `assert_eq!` data structure size assertions that had failed on
32-bit targets were to safeguard against the size increasing, so
using a `==` comparison on 64-bit targets and a `<=` comparison to
the same value on 32-bit targets was a suitable fix, which allowed
18 tests to go from failing to passing in the 32-bit container.
However, four remaining tests that assert sizes of buffers or
streamed data are not just for flagging increases, but are instead
cases where a change in either direction, on any platform, should
probably draw attention. The most important of these to keep `==`,
even on 32-bit platforms, may be two tests that assert the same
value for complementary operations:
- gix::gix repository::worktree::archive
- gix::gix repository::worktree::stream
But I think it's useful to do this in the two others, too:
- gix-archive::archive from_tree::basic_usage_internal
- gix-worktree-stream::stream from_tree::will_provide_all_information_and_respect_export_ignore
This commit adds constants with different 64-bit and 32-bit values
for the three buffer lengths asserted in those four tests (the
two `gix::gix repository::worktree::*` assert the same length).
This change should make the four remaining tests that had been
failing on the 32-bit container, and 32-bit GNU/Linux targets in
general, pass on them.
In specifying the expected 32-bit buffer lengths, I have treated
these as approval tests, rather than inferring that the exact
length and no other length must be correct. The asserted lengths:
- Appeared as the value when the tests were run in the 32-bit
container.
- Are verified to appear repeatedly across different runs in the
container as well as in runs on a non-containerized 32-bit Debian
12 system.
- Are equal to the values in assertion messages for the same failed
tests run on a 32-bit Windows 10 system. This is significant
because some values differ between different 32-bit targets, even
targets for the same 32-bit architecture, and two such targets
where I've observed differences are `i686-unknown-linux-gnu` and
`i686-pc-windows-msvc`.
- Are, of course, less than the 64-bit sizes, not greater.
- Make sense on inspection. (But please note that this is not the
same as an analysis that proves they are the only possible
correct values.)
0 commit comments