[issue1789] incorrect assumption about unsigned long byte size

[Christopher Yeleighton]

New submission from Christopher Yeleighton:

Text of section 11.3 "Working with Binary Data Record Layouts" at

incorrectly assumes that unsigned long is 4 bytes long (with pack codes
"H" and "L" representing two and four byte unsigned numbers
respectively).  It is may be a valid description of the author’s
environment, but it is invalid as a general statement and it creates the
wrong impression that the sample programme is portable and ready-to-go.

--
components: Documentation
messages: 59704
nosy: spe-anatol
severity: normal
status: open
title: incorrect assumption about unsigned long byte size
type: behavior
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1789] incorrect assumption about unsigned long byte size

[Gregory P. Smith]

Gregory P. Smith added the comment:

the docs I see in the URL you give are correct as it states 'two and
four byte unsigned integer respectively' for H and L.  However the
example is missing the < for little-endian; I'll add that.

Also, I notice that the struct module documentation itself incorrectly
uses the C terms 'int' and 'long' to assume 32bit and long long when it
means 64bit.  I'll fix that.

--
assignee:  -> gregory.p.smith
keywords: +easy
nosy: +gregory.p.smith
priority:  -> normal

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1789] incorrect assumption about unsigned long byte size

[Christopher Yeleighton]

Christopher Yeleighton added the comment:

Python 2.5.1 (r251:54863, Oct  5 2007, 13:50:07) 
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> g_f = open('/dev/null')
>>> struct.unpack('L', g_f.read(04))
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.5/struct.py", line 87, in unpack
return o.unpack(s)
struct.error: unpack requires a string argument of length 8

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1789] incorrect assumption about unsigned long byte size

[Gregory P. Smith]

Gregory P. Smith added the comment:

eew, so the struct module does map as documented to the C types listed
in the docs.  yuck.  regardless, changing the Ls to Is will fix the
tutorial document code.  I'll do that.

I believe there are also other instances of wrong uses of L in struct in
the code such as the zipfile module that will fail on LP64 platforms. 
I'll look for those (and why they weren't caught by unit tests).

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1789] incorrect assumption about unsigned long byte size

[Gregory P. Smith]

Gregory P. Smith added the comment:

The documentation for the struct module says:

 "short is 2 bytes; int and long are 4 bytes; long long (__int64 on
Windows) is 8 bytes"

and lists 'l' and 'L' as the pack code for a C long.

As it is implemented today, the documentation is incorrect.  On an LP64
host (pretty much any 64-bit linux, bsd or unixish OS; not windows) a
long is 8 bytes.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com