Re: Struct usage and varying sizes of h, l, etc

[Robert Kern]

Ethan Furman wrote:

Greetings,

I'm looking at the struct module for binary packing of ints and floats.
The documentation refers to C datatypes. It's been many years since I
looked at C, but I seem to remember that the data type sizes were not
fixed -- for example, an int might be two byes on one machine, and four
bytes on the next. Can any C programmers verify this? If it is true,
does that mean that struct.pack('h', 8001) might give me different
results depending on the machine it's running on?

Right. I believe (but could be wrong) that "char" is defined to be one byte, but
that "short", "int", "long", and "long long" are defined as "at least as big as
the previous type".

In practice, though, on nearly every machine that Python runs on, "char" is one
byte, "short" is two bytes, and "int" is four bytes. "longs" and "long longs"
tend to vary substantially, though; never assume sizes for them.

Single-precision floats are always four bytes and double-precision floats are
always eight bytes. "long doubles" vary; they could be twelve bytes or sixteen.

If you want to deal with fixed sizes, use struct.calcsize() to test the sizes of
each of the integer types, assign them to width-specific aliases, and always use
these aliases.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

[Dan Bishop]

On May 20, 5:59*pm, Robert Kern <[e-mail]:

Ethan Furman wrote:

Greetings,

I'm looking at the struct module for binary packing of ints and floats. *
The documentation refers to C datatypes. *It's been many years since I
looked at C, but I seem to remember that the data type sizes were not
fixed -- for example, an int might be two byes on one machine, and four
bytes on the next. *Can any C programmers verify this? *If it is true,
does that mean that struct.pack('h', 8001) might give me different
results depending on the machine it's running on?

Right. I believe (but could be wrong) that "char" is defined to be one byte, but
that "short", "int", "long", and "long long" are defined as "at least as big as
the previous type".

There are also minimum sizes for each type:

char: 8 bits
short: 16 bits
int: 16 bits
long: 32 bits
long long: 64 bits

In practice, though, on nearly every machine that Python runs on, "char" is one
byte, "short" is two bytes, and "int" is four bytes. "longs" and "long longs"
tend to vary substantially, though; never assume sizes for them.

Single-precision floats are always four bytes and double-precision floats are
always eight bytes. "long doubles" vary; they could be twelve bytes or sixteen.

If you want to deal with fixed sizes, use struct.calcsize() to test the sizes of
each of the integer types, assign them to width-specific aliases, and always use
these aliases.

Also, according to the documentation for the struct module, the =, <,
and format characters specify "std. size" rather than "native size".

[Grant Edwards]

On 2008-05-20, Robert Kern <ro*********@gmail.comwrote:

>I'm looking at the struct module for binary packing of ints
and floats. The documentation refers to C datatypes. It's
been many years since I looked at C, but I seem to remember
that the data type sizes were not fixed -- for example, an int
might be two byes on one machine, and four bytes on the next.
Can any C programmers verify this? If it is true, does that
mean that struct.pack('h', 8001) might give me different
results depending on the machine it's running on?

Right. I believe (but could be wrong) that "char" is defined
to be one byte,

Yes, C defines "char" to be one byte, but it doesn't define the
size of a "byte" other than it's at least big enough to hold
one character (or something like that). In practice, a byte is
pretty much guaranteed to be at least 8 bits. But, on some
targets a "byte" is 16 bits, and on others a byte is 32 bits.

However, I'm not aware of any Python implementations on those
targets...

--
Grant Edwards grante Yow! Clear the laundromat!!
at This whirl-o-matic just had
visi.com a nuclear meltdown!!

[sjdevnull]

On May 21, 10:04 am, Grant Edwards <[e-mail]:

Yes, C defines "char" to be one byte, but it doesn't define the
size of a "byte" other than it's at least big enough to hold
one character (or something like that). In practice, a byte is
pretty much guaranteed to be at least 8 bits.

If you're discussing standard C, you can omit "in practice" and
"pretty much". CHAR_BITS is required to be at least 8 by the ANSI/ISO
C Standard.

But, on some targets a "byte" is 16 bits, and on others a byte
is 32 bits.

Yep, or 9 bits or 36 bits, or anything >= 8.

[Robert Kern]

Ethan Furman wrote:

Next question: when using struct.pack to store an integer, I get a
deprecation warning if the int is too big... I would rather have an
error. Is there a setting somewhere that controls this?

http://docs.python.org/dev/library/warnings

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco