[cppyy] Treat long and long long buffer formats as interchangeable - #23580
Open
guitargeek wants to merge 3 commits into
Open
guitargeek wants to merge 3 commits into
guitargeek wants to merge 3 commits into
Conversation
Test Results 24 files 24 suites 3d 22h 0m 51s ⏱️ For more details on these failures, see this check. Results for commit ed88e95. ♻️ This comment has been updated with latest results. |
numpy and other buffer producers canonicalize the PEP 3118 format char of 64-bit integer dtypes (e.g. int64 is always reported as 'l' on 64-bit platforms), but C++ parameters declared as int64_t resolve to 'long long' on macOS and 'long' on Linux. The exact format-char matching in the array converters therefore rejected valid buffers when the resolved type and the canonicalized buffer format differed, breaking e.g. passing numpy int64 arrays to 'const int64_t*' parameters on macOS. Add Utility::FormatCodeCompatible() and use it where buffer formats are matched: Utility::GetBuffer() (standard buffer protocol), CArraySetArg() (low-level views), the 2-dimensional branch of the array converter, and StdSpanConverter (std::span parameters). As before, the item-size check guards against actual size mismatches. Ported from the deleted cppyy bindings (CPyCppyy) to the vendored cppjit cpyrt sources, after PyROOT was rewired from the cppyy stack to cppjit. 🤖 Done with the help of AI
…NN tutorial" This reverts commit bb5fa27. The conversion of numpy int64 arrays to 'const int64_t*' parameters is now fixed in cppyy itself, which treats same-sized 'long' and 'long long' buffer formats as interchangeable, so the explicit cppyy.ll.cast workaround is not needed anymore; the tutorial passes the numpy arrays directly again.
Replace the ad-hoc buffer-format matching with a small PEP 3118 parser.
Formats are reduced to their element type (skipping byte-order prefixes
like ctypes' '<q', repeat counts, and the 'Z' complex marker), classified
by kind (signed/unsigned integer, float, complex, ...) and native size,
and accepted when both match the requested type code.
This subsumes all previously scattered special cases:
- int/long equivalence on Windows and 32-bit Linux in GetBuffer()
- long/long long interchange for numpy's canonicalized int64 format
- 'z'/'Zf' complex-float naming
- signed char ('b') as bool, kept as an explicit documented quirk
and generalizes to both 1-dim and 2-dim LowLevelView branches and to
std::span. As side effects, ctypes' explicitly-endian '<q'/'<d' buffers
are now accepted natively, and complex buffers no longer leak into float
parameters through the 'Zd'-contains-'d' substring accident (std::span,
which performs no item-size check, previously read complex128 buffers as
double).
🤖 Done with the help of AI
guitargeek
force-pushed
the
sofie-fixup
branch
from
October 4, 2026 08:25
cf358bd to
ed88e95
Compare
This branch has not been deployed
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.
numpy and other buffer producers canonicalize the PEP 3118 format char of 64-bit integer dtypes (e.g. int64 is always reported as 'l' on 64-bit platforms), but C++ parameters declared as int64_t resolve to 'long long' on macOS and 'long' on Linux. The exact format-char matching in the array converters therefore rejected valid buffers when the resolved type and the canonicalized buffer format differed, breaking e.g. passing numpy int64 arrays to 'const int64_t*' parameters on macOS.
Add Utility::FormatCodeCompatible() and use it where buffer formats are matched: Utility::GetBuffer() (standard buffer protocol), CArraySetArg() (low-level views), and the 2-dimensional branch of the array converter. As before, the item-size check guards against actual size mismatches.
🤖 Done with the help of AI