struct.pack bug?

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Jansson Christer

    #1

    struct.pack bug?

    Hi all,

    I have discovered that in my Python 2.4.1 installation (on Solaris 8),
    struct.pack handles things in a way that seems inconsistent to me.

    I haven't found any comprehensible documentation over known issues with
    Python 2.4.1 so I try this...

    Here's the thing:
    >>from struct import pack
    >>pack('B', -1)
    Traceback (most recent call last):
    File "<stdin>", line 1, in ?
    struct.error: ubyte format requires 0<=number<=255
    >>pack('H', -1)
    Traceback (most recent call last):
    File "<stdin>", line 1, in ?
    struct.error: short format requires 0<=number<=USHR T_MAX
    >>pack('L', -1)
    '\xff\xff\xff\x ff'
    >>>
    Shouldn't pack('L', -1) raise an exception like the others, rather than
    behaving like pack('l', -1)?
    Is this fixed in later versions?

    (I don't have access to later versions and have failed to install any.
    Python 2.5 compiles nicely but "make install" fails without leaving any
    clues about how it failed and no installation troubleshooting guides to
    be found at python.org. Python 2.4.4 doesn't even compile since it
    apparently requires a newer libstdc++ than the one on our system... see
    why I'm asking the newsgroup?)

    --
    --

    Christer Jansson
    WiseOne AB
    +46 708 21 42 84
  • Fredrik Lundh

    #2
    Re: struct.pack bug?

    "Jansson Christer" wrote:
    I have discovered that in my Python 2.4.1 installation (on Solaris 8),
    struct.pack handles things in a way that seems inconsistent to me.
    >
    I haven't found any comprehensible documentation over known issues with
    Python 2.4.1 so I try this...
    >
    Here's the thing:
    >
    >from struct import pack
    >pack('B', -1)
    Traceback (most recent call last):
    File "<stdin>", line 1, in ?
    struct.error: ubyte format requires 0<=number<=255
    >pack('H', -1)
    Traceback (most recent call last):
    File "<stdin>", line 1, in ?
    struct.error: short format requires 0<=number<=USHR T_MAX
    >pack('L', -1)
    '\xff\xff\xff\x ff'
    >>
    >
    Shouldn't pack('L', -1) raise an exception like the others, rather than
    behaving like pack('l', -1)?
    probably; the reason for the old behaviour is probably to simplify for code that
    uses Python int's to represent 32-bit values. (mixing longs and ints used to be a
    lot more difficult than it is today).
    Is this fixed in later versions?
    the "struct" module was rewritten in Python 2.5; the new module issues a
    warning, and then appears to *clamp* the value to the allowed range, in-
    stead of grabbing the low bits:
    >>import struct
    >>struct.pack(" B", -1)
    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "C:\Python25\Li b\struct.py", line 63, in pack
    return o.pack(*args)
    struct.error: ubyte format requires 0 <= number <= 255
    >>struct.pack(" H", -1)
    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "C:\Python25\Li b\struct.py", line 63, in pack
    return o.pack(*args)
    struct.error: short format requires 0 <= number <= USHRT_MAX
    >>struct.pack(" I", -1)
    __main__:1: DeprecationWarn ing: 'I' format requires 0 <= number <= 4294967295
    '\x00\x00\x00\x 00'
    >>struct.pack(" L", -1)
    __main__:1: DeprecationWarn ing: 'L' format requires 0 <= number <= 4294967295
    '\x00\x00\x00\x 00'

    </F>



    Comment

    • Jansson Christer

      #3
      Re: struct.pack bug?

      Fredrik Lundh wrote:
      "Jansson Christer" wrote:
      >
      >
      >>I have discovered that in my Python 2.4.1 installation (on Solaris 8),
      >>struct.pack handles things in a way that seems inconsistent to me.
      >>
      >>I haven't found any comprehensible documentation over known issues with
      >>Python 2.4.1 so I try this...
      >>
      >>Here's the thing:
      >>
      >>
      >>>>>from struct import pack
      >>>>>pack('B' , -1)
      >>
      >>Traceback (most recent call last):
      > File "<stdin>", line 1, in ?
      >>struct.erro r: ubyte format requires 0<=number<=255
      >>
      >>>>>pack('H' , -1)
      >>
      >>Traceback (most recent call last):
      > File "<stdin>", line 1, in ?
      >>struct.erro r: short format requires 0<=number<=USHR T_MAX
      >>
      >>>>>pack('L' , -1)
      >>
      >>'\xff\xff\xff \xff'
      >>
      >>Shouldn't pack('L', -1) raise an exception like the others, rather than
      >>behaving like pack('l', -1)?
      >
      >
      probably; the reason for the old behaviour is probably to simplify for code that
      uses Python int's to represent 32-bit values. (mixing longs and ints used to be a
      lot more difficult than it is today).
      >
      >
      >>Is this fixed in later versions?
      >
      >
      the "struct" module was rewritten in Python 2.5; the new module issues a
      warning, and then appears to *clamp* the value to the allowed range, in-
      stead of grabbing the low bits:
      >
      >
      >>>>import struct
      >
      >
      >>>>struct.pack ("B", -1)
      >
      Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "C:\Python25\Li b\struct.py", line 63, in pack
      return o.pack(*args)
      struct.error: ubyte format requires 0 <= number <= 255
      >
      >
      >>>>struct.pack ("H", -1)
      >
      Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "C:\Python25\Li b\struct.py", line 63, in pack
      return o.pack(*args)
      struct.error: short format requires 0 <= number <= USHRT_MAX
      >
      >
      >>>>struct.pack ("I", -1)
      >
      __main__:1: DeprecationWarn ing: 'I' format requires 0 <= number <= 4294967295
      '\x00\x00\x00\x 00'
      >
      >
      >>>>struct.pack ("L", -1)
      >
      __main__:1: DeprecationWarn ing: 'L' format requires 0 <= number <= 4294967295
      '\x00\x00\x00\x 00'
      >
      </F>
      >
      >
      >
      Ok this implies that somebody is actually thinking about how to handle
      this, so I guess I won't file a bug report and simply solve my problems
      without relying on those exceptions...

      Thank you!
      --
      --

      Christer Jansson
      WiseOne AB
      +46 708 21 42 84

      Comment

      Working...