0

Context

I have an application which outputs data into files and which verifies the data via checksums. While everything was working correctly with Python 3.8.0 32bit, I observed different checksums being generated with Python 3.8.4 64bit. Following the data that was being dumped incorrectly, I believe I've narrowed it down to this code (as the files that fail are the only ones using this function).

The purpose of this method is to take a single value, 0-65535, and split it into two separate "bytes".

def integer_to_lsb_msb(value: int) -> List[int]:

    if value < 0 or value > 65535:
        raise ValueError("The input value does not qualify as a '16bit' value", value)

    lsb = value & 0xFF
    msb = ((value >> 8) & 0xFF)
    return [lsb, msb]

Question

Does python not process code in an architecture independent way? If not, is there a way to check the architecture and run custom code to ensure identical output with both 32bit and 64bit versions?

BlackBox
  • 2,223
  • 1
  • 21
  • 37
  • So show us an input where the two different Python versions give different results with this function? – Manuel Apr 13 '21 at 11:18
  • 2
    Python's bit-wise operators are operators on integers, not computer words -- so I doubt that you have an example of a function that sends ints to int lists and returns different values on different architectures. My guess is that what you are seeing has more to do with what you *do* with the returned value (in code that you haven't shown). Without a [mcve] it is hard to say any more than that. – John Coleman Apr 13 '21 at 11:23
  • The point of the question is not as you're interpreting it. I have code which generates different output based on whether or not I'm using 32 or 64 bit versions of python. Therefore the question is about the rules of the python interpreter and whether or not this shoulder ever be the case. – BlackBox Apr 13 '21 at 11:32
  • 3
    A [mcve] would consist of a short program which generates different output on different versions. The code that you have posted seems to lack that property. Is there a specific `value` for which `print(integer_to_lsb_msb(value))` prints something different on different machines? If not, why did you even post that function? – John Coleman Apr 13 '21 at 11:40
  • 1
    Are you using `bytes` objects in your code? Methods like `int.from_bytes` involve low-level details and might behave differently on different architectures. – John Coleman Apr 13 '21 at 11:51
  • @JohnColeman What low-level details does `int.from_bytes` involve that might make it behave differently? – Manuel Apr 13 '21 at 12:36
  • @Manuel I can't think of any (hence my hedge "might") -- but perhaps it depends on where those bytes come from. That method involves specifying byte order and whether or not the bytes represent a signed integer. What that implies for 32 vs 64 bits in Python, I don't know, but it strikes me as the sort of thing that *might* make a difference, e.g. if the code is constructing bytes-objects from binary files. – John Coleman Apr 13 '21 at 12:52

1 Answers1

0

The python interpreter should run the code independent from the architecture. So you shouldn't worry about it in your code. For instance, "All integers are implemented as “long” integer objects of arbitrary size" (Python Doc).

Nevertheless you may encounter problems if you load external libraries whose bitness is different from your interpreter's (Should I use Python 32bit or Python 64bit), such as DLL's in Windows.

Gabriel A.
  • 609
  • 3
  • 7
  • In Windows, you *can't* load a DLL whose bitness is different from the interpreter's. Trying to do so can result in any of several errors such a Not a valid win32 program or Not found. But it won't run and give unexpected results. – BoarGules Apr 13 '21 at 12:49