Skip to content

src/msgspec/_core.c: Fix backing type declaration of Ext.code - #1135

Merged
sobolevn merged 2 commits into
msgspec:mainfrom
OPNA2608:fix/Ext.code-big-endian
Aug 11, 2026
Merged

src/msgspec/_core.c: Fix backing type declaration of Ext.code#1135
sobolevn merged 2 commits into
msgspec:mainfrom
OPNA2608:fix/Ext.code-big-endian

Conversation

@OPNA2608

@OPNA2608 OPNA2608 commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

Fixes the TestExt test suite on big-endian systems.

(Ext).code is implemented by a long in the C code, but declared to be backed by an int for access from Python. Correct this.

When long is larger than int, the previous declaration caused only an endian-specific part of the code value to get returned when read from Python-land. On little-endian it was the lower half, and with the valid range of code values being small enough to fit in 1 byte, everything seemed fine.

On big-endian, this returned the upper half of the long instead, so all asserts of (Ext).code values failed because the only possible values were 0 and -1.

Example output of the tests on a big-endian machine (powerpc64-linux) before this change:

=========================== short test summary info ============================
FAILED tests/unit/test_msgpack.py::TestExt::test_init[test] - assert 0 == 1
FAILED tests/unit/test_msgpack.py::TestExt::test_init[data1] - assert 0 == 1
FAILED tests/unit/test_msgpack.py::TestExt::test_init[data2] - assert 0 == 1
FAILED tests/unit/test_msgpack.py::TestExt::test_code_roundtrip[-128] - assert -1 == -128
FAILED tests/unit/test_msgpack.py::TestExt::test_code_roundtrip[-2] - assert -1 == -2
FAILED tests/unit/test_msgpack.py::TestExt::test_code_roundtrip[2] - assert 0 == 2
FAILED tests/unit/test_msgpack.py::TestExt::test_code_roundtrip[127] - assert 0 == 127
FAILED tests/unit/test_msgpack.py::TestExt::test_pickleable - assert 0 == 1
FAILED tests/unit/test_msgpack.py::TestExt::test_roundtrip[0] - assert 0 == 5
FAILED tests/unit/test_msgpack.py::TestExt::test_roundtrip[1] - assert 0 == 5
FAILED tests/unit/test_msgpack.py::TestExt::test_roundtrip[2] - assert 0 == 5
FAILED tests/unit/test_msgpack.py::TestExt::test_roundtrip[4] - assert 0 == 5
FAILED tests/unit/test_msgpack.py::TestExt::test_roundtrip[8] - assert 0 == 5
FAILED tests/unit/test_msgpack.py::TestExt::test_roundtrip[16] - assert 0 == 5
FAILED tests/unit/test_msgpack.py::TestExt::test_roundtrip[31] - assert 0 == 5
FAILED tests/unit/test_msgpack.py::TestExt::test_roundtrip[32] - assert 0 == 5
FAILED tests/unit/test_msgpack.py::TestExt::test_roundtrip[255] - assert 0 == 5
FAILED tests/unit/test_msgpack.py::TestExt::test_roundtrip[256] - assert 0 == 5
FAILED tests/unit/test_msgpack.py::TestExt::test_roundtrip[65535] - assert 0 == 5
FAILED tests/unit/test_msgpack.py::TestExt::test_roundtrip[65536] - assert 0 == 5
=========== 20 failed, 5798 passed, 379 skipped in 74.33s (0:01:14) ============

@OPNA2608
src/msgspec/_core.c: Fix backing type declaration of Ext.code
85a1278 
Fixes the TestExt test suite on big-endian systems.

`(Ext).code` is implemented by a `long` in the C code, but declared to be backed by an `int` for access from Python. Correct this.

When `long` is larger than `int`, the previous declaration caused only an endian-specific part of the `code` value to get
returned when read from Python-land. On little-endian it was the lower half, and with the valid range of `code` values being
small enough to fit in 1 byte, everything seemed fine.

On big-endian, this returned the upper half of the `long` instead, so all `assert`s of `(Ext).code` values failed because
the only possible values were 0 and -1.
jcrist
jcrist approved these changes Aug 7, 2026
View reviewed changes

@jcrist jcrist left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@OPNA2608 OPNA2608 mentioned this pull request Aug 7, 2026
Merged
14 tasks
@codspeed

codspeed Bot commented Aug 7, 2026 •
edited
Loading

Copy link
Copy Markdown

Merging this PR will improve performance by ×12

⚡ 2 improved benchmarks
✅ 137 untouched benchmarks
⏩ 135 skipped benchmarks1

Performance Changes

Mode Benchmark BASE HEAD Efficiency
⚡ Simulation test_import_time[arm-msgspec.inspect] 17,133.4 µs 137.5 µs ×120
⚡ Simulation test_decode_type[arm-msgpack-False] 849.5 µs 758.6 µs +11.98%

Tip

Curious why this is faster? Comment @codspeedbot explain why this is faster on this PR, or directly use the CodSpeed MCP with your agent.

Comparing OPNA2608:fix/Ext.code-big-endian (dc8bca6) with main (dcfd447)

Open in CodSpeed

Footnotes

  1. 135 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

sobolevn
sobolevn approved these changes Aug 11, 2026
View reviewed changes

@sobolevn sobolevn left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!
It will make into the 0.22.0 release.

@sobolevn
sobolevn added this pull request to the merge queue Aug 11, 2026
Merged via the queue into msgspec:main with commit c24bc70 Aug 11, 2026
26 of 27 checks passed
@Siyet Siyet mentioned this pull request Sep 4, 2026
Merged
Brohammad pushed a commit to Brohammad/msgspec that referenced this pull request Sep 4, 2026
@Siyet
Add missing 0.22.0 changelog entries (msgspec#1171)
f5abcee 
The 0.21.1 to 0.22.0 changelog batch (msgspec#1112) landed on 2026-07-03. Four
user-visible changes merged between then and the 0.22.0 release on
2026-08-11 never got an entry:

- msgspec#700, overloads on the `Meta` stub, so type checkers reject mixing
`gt` with `ge` and `lt` with `le`
- msgspec#1028, `null` placed last in the `anyOf` generated for optional unions
- msgspec#1114, `__struct_encode_fields__` added to `src/msgspec/__init__.pyi`
(its companion msgspec#813 only touched `tests/typing`, so it needs no entry of
its own)
- msgspec#1118, `json.encode` raising `TypeError` for a `dict` keyed by a plain
`str`-valued `enum.Enum`

I went over every PR merged in that window. The rest need no entry: msgspec#813
and msgspec#1117 are tests only, msgspec#1121 fixes an unreleased regression from
msgspec#1028, msgspec#1145 is an unused variable under free-threaded builds, and msgspec#1146
and msgspec#1148 are CI and tooling. msgspec#1127, msgspec#1135 and msgspec#1080 already have
entries.

Docs build clean with `--fail-on-warning`.

Note for whoever retries the release: the section is still headed
`Version 0.22.0 (2026-08-11)`, and that date will need updating, since
the tag was deleted after the upload failed. Refs msgspec#1134.

Co-authored-by: Siyet <Siyet@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@jcrist jcrist jcrist approved these changes
@sobolevn sobolevn sobolevn approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@OPNA2608 @jcrist @sobolevn