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
{{ message }}
Repository navigation
Commit f9c1438
Browse filesBrowse the repository at this point in the historyBrowse files
fix: byte-order bugs and little-endian test assumptions on big-endian hosts (#4435)
* fix: byte-order bugs and little-endian test assumptions on big-endian hosts
Running the suite on s390x (QEMU, Debian sid) gave 110 failures on main.
Most came from one asymmetry: V3 data types without an explicit byte
order defaulted to little-endian, while NumPy dtype names mean host order.
On a big-endian host `dtype="float64"` and `dtype=np.float64` produced
different data types, and a reopened array changed dtype.
- V3 data types default to the host byte order (`HasEndianness`), because
V3 metadata carries none. Stored chunks stay little-endian by default.
- `ShardingCodec` defaults its inner and index `bytes` codecs to
little-endian, so sharded output no longer depends on the host.
- `scale_offset` computes in native byte order and restores the input's
byte order; `>f8` and `>u8` arrays failed on every host.
- Base64 fill values of structured data types in V3 metadata are
little-endian bytes in both directions.
- Tests no longer assume a little-endian host: explicit `<` dtypes and
`endian="little"` where the expectation is little, and a big-endian case
for migration and pipeline parity.
Refs #3438
Assisted-by: ClaudeCode:claude-opus-5-5
* docs: name the changelog fragment after the PR
Assisted-by: ClaudeCode:claude-opus-5-5
* ci: run byte-order-sensitive tests on s390x under QEMU
A weekly and path-filtered job that runs the data type, codec and metadata
tests on an emulated big-endian host, in a Debian sid image that takes numpy
and numcodecs from Debian packages so nothing heavy compiles under emulation.
Assisted-by: ClaudeCode:claude-opus-5-5
* fix(codecs)!: BytesCodec defaults to little-endian on every host
`BytesCodec()` defaulted to `sys.byteorder`, so the same code wrote
big-endian chunks on s390x and little-endian chunks elsewhere. The bytes
codec originally defaulted to "little"; the host default came in as a side
effect of replacing attrs with dataclasses (#1660), and was later pinned
by a test that only restated it. `"little"` also matches
`default_serializer_v3`.
Chunks written on big-endian hosts with a bare `BytesCodec()` are now
little-endian. Chunks written before this change remain readable, because
the codec records its byte order in the metadata.
Refs #3438
Assisted-by: ClaudeCode:claude-opus-5-5
* revert: keep the BytesCodec default out of this PR
This reverts commit 8dd33e3. Changing the default of `BytesCodec()`
changes what existing code writes on big-endian hosts, so it needs a
deprecation cycle and will land in its own PR.
Assisted-by: ClaudeCode:claude-opus-5-5
Fix byte-order bugs found by running the test suite on a big-endian (s390x) host.
2
+
3
+
- Zarr V3 data type metadata has no byte order, so V3 data types without an explicit `endianness` (such as `Float64()`, or a data type parsed from `"float64"`) now use the host byte order instead of always little-endian. On big-endian hosts, arrays opened from V3 metadata now return native arrays, and `dtype="float64"` and `dtype=np.float64` produce the same data type. Nothing changes on little-endian hosts. Stored chunks are still little-endian by default.
4
+
-`ShardingCodec` now defaults its inner and index `bytes` codecs to little-endian, so sharded arrays written with default settings are byte-identical on every host.
5
+
- The `scale_offset` codec no longer fails on arrays whose byte order is not the host's, for example a `">f8"` or `">u8"` array on a little-endian host.
6
+
- Base64-encoded fill values of structured data types in Zarr V3 metadata are now read and written as little-endian bytes, whatever the byte order of the fields in memory.
7
+
- Tests no longer assume that the host is little-endian.
0 commit comments