Skip to content

Conversation

@Komorebi-Z
Copy link
Contributor

In Python 3.12 and newer, the PyLongObject struct was changed, making Py_SIZE() unreliable for getting the length of the digit array. This issue caused longObjToMPZ() to incorrectly determine the length of long_obj during the initialization function Element_elem() in charm/core/math/pairing/pairingmodule.c, leading to incorrect conversion behavior.

The following changes have been implemented:

  1. Introduced PyLongObj_Size macro to calculate the size of PyLongObject struct.
  2. Renamed PythonLongVal to PyLongObj_Val to improve naming consistency.

This probably fixes issue #326, but further testing on different Python versions is recommended for caution.

Note: Further adjustments may be required for Python 3.14+ due to potential shifts to new C APIs, as detailed in PEP 757.

In Python 3.12 and newer, the `PyLongObject` struct was changed, making `Py_SIZE()` unreliable for getting the length of the digit array.

The following changes have been implemented:

1. Introduced `PyLongObj_Size` macro to calculate the size of `PyLongObject` struct.
2. Renamed `PythonLongVal` to `PyLongObj_Val` to improve naming consistency.

**Note**: Further adjustments may be required for Python 3.14+ due to potential shifts to new C APIs, as detailed in PEP 757.
@BatchClayderman
Copy link
Contributor

Hi, guys. Thank you so much for fixing those issues in ZR.
As I am not quite familiar with PairingGroup operations, I am also interested in whether the following operations of G1 elements are outputting correct results in Python 3.12. Thanks a lot.

Python 3.12.3 (main, Feb  4 2025, 14:48:35) [GCC 13.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from charm.toolbox.pairinggroup import PairingGroup, G1, G2, GT, ZR, pair, pc_element as Element
>>> group = PairingGroup("MNT159")
>>> a = group.random(G1)
>>> a
[301187472002304746619209247963206559947998705076, 121731044715532841670820951857195078999418162]
>>> group.init(G1, 1)
O
>>> group.init(G1, 2)
O
>>> group.init(G1, 3)
O
>>> a * group.init(G1, 1)
[301187472002304746619209247963206559947998705076, 121731044715532841670820951857195078999418162]
>>> a * group.init(G1, 2)
[301187472002304746619209247963206559947998705076, 121731044715532841670820951857195078999418162]
>>> a * group.init(G1, 3)
[301187472002304746619209247963206559947998705076, 121731044715532841670820951857195078999418162]
>>>

@Komorebi-Z
Copy link
Contributor Author

@BatchClayderman Don't worry, this is normal and depends on the implementation of the set_mpz method in different groups. Taking PBC as an example, group.init(G1, 2) eventually calls zero_set_mpz located here, which is designed to ignore the input value.

@jakinyele jakinyele self-requested a review June 19, 2025 05:00
Copy link
Member

@jakinyele jakinyele left a comment

Choose a reason for hiding this comment

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

This is a good catch. Thanks for the PR @Komorebi-Z.

@jakinyele jakinyele merged commit 8d56d75 into JHUISI:dev Jun 19, 2025
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants