msgpack/msgpack-python

[Feature request] Cast integer to the lowest precision without overflow during encoding

caniko opened this issue · 5 comments

caniko commented

Issue
Message pack integer, behavior is different across golang and Python. Consider that we have the integer 10000, and store this in Python, it may be any integer precision. This is not the case in go, when encoding int 10000 will always be 64-bits on 64-bit machines.

This leads to different encoded values across the languages even though the underlying values are the same.

Solution
When working with precision, let the client inject their preferred precision to packb.

"Your issue, not mine" solution
Add this to the documentation so that others don't have the same pain as we did, figure this out. Include an example of how to force the precision using ctypes:

import ctypes

def to_uint32(x):
    return ctypes.c_uint32(x).value

# Example usage
num = to_uint32(123456789)
print(num)  # Output: 123456789

# Example: Overflow behavior
num = to_uint32(2**32 + 123)
print(num)  # Output: 123, demonstrating overflow
methane commented

Doesn't make sense at all.
Wrong guess, wrong solution.

  • 👍1
  • 👎1
caniko commented

@methane, let's try to be civil, and try to steer away from antipatterns. Please don't close an issue before there is a mutual understanding of the problem.

I realize I had it the other way around, it is Python that picks an arbitrary precision. There has to be a way to know what precision will be used, currently it is impossible.

Updated the body.

methane commented

@methane, let's try to be civil, and try to steer away from antipatterns. Please don't close an issue before there is a mutual understanding of the problem.

Let's try to be civil, do not post issue until you understand the issue or you can provide minimum complete step to reproduce. OSS maintainers are receiving dozen notifications every day and tend to ignore notification and burn out.

caniko commented

OK