1992-08-17 08:55:12 +00:00
|
|
|
/***********************************************************
|
1995-01-04 19:10:35 +00:00
|
|
|
Copyright 1991-1995 by Stichting Mathematisch Centrum, Amsterdam,
|
|
|
|
The Netherlands.
|
1992-08-17 08:55:12 +00:00
|
|
|
|
|
|
|
All Rights Reserved
|
|
|
|
|
1996-10-25 14:44:06 +00:00
|
|
|
Permission to use, copy, modify, and distribute this software and its
|
|
|
|
documentation for any purpose and without fee is hereby granted,
|
1992-08-17 08:55:12 +00:00
|
|
|
provided that the above copyright notice appear in all copies and that
|
1996-10-25 14:44:06 +00:00
|
|
|
both that copyright notice and this permission notice appear in
|
1992-08-17 08:55:12 +00:00
|
|
|
supporting documentation, and that the names of Stichting Mathematisch
|
1996-10-25 14:44:06 +00:00
|
|
|
Centrum or CWI or Corporation for National Research Initiatives or
|
|
|
|
CNRI not be used in advertising or publicity pertaining to
|
|
|
|
distribution of the software without specific, written prior
|
|
|
|
permission.
|
|
|
|
|
|
|
|
While CWI is the initial source for this software, a modified version
|
|
|
|
is made available by the Corporation for National Research Initiatives
|
|
|
|
(CNRI) at the Internet address ftp://ftp.python.org.
|
|
|
|
|
|
|
|
STICHTING MATHEMATISCH CENTRUM AND CNRI DISCLAIM ALL WARRANTIES WITH
|
|
|
|
REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF
|
|
|
|
MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL STICHTING MATHEMATISCH
|
|
|
|
CENTRUM OR CNRI BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL
|
|
|
|
DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
|
|
|
|
PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
|
|
|
|
TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
|
|
|
|
PERFORMANCE OF THIS SOFTWARE.
|
1992-08-17 08:55:12 +00:00
|
|
|
|
|
|
|
******************************************************************/
|
|
|
|
|
|
|
|
/* struct module -- pack values into and (out of) strings */
|
|
|
|
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
/* New version supporting byte order, alignment and size options,
|
|
|
|
character strings, and unsigned numbers */
|
|
|
|
|
1996-12-12 23:32:31 +00:00
|
|
|
#include "Python.h"
|
1997-01-02 22:21:36 +00:00
|
|
|
#include "mymath.h"
|
1992-08-17 08:55:12 +00:00
|
|
|
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
#include <limits.h>
|
|
|
|
|
|
|
|
|
|
|
|
/* Exception */
|
|
|
|
|
1996-12-12 23:32:31 +00:00
|
|
|
static PyObject *StructError;
|
1992-08-17 08:55:12 +00:00
|
|
|
|
|
|
|
|
|
|
|
/* Define various structs to figure out the alignments of types */
|
|
|
|
|
1995-02-02 14:29:10 +00:00
|
|
|
#ifdef __MWERKS__
|
|
|
|
/*
|
|
|
|
** XXXX We have a problem here. There are no unique alignment rules
|
|
|
|
** on the PowerPC mac.
|
|
|
|
*/
|
|
|
|
#ifdef __powerc
|
|
|
|
#pragma options align=mac68k
|
|
|
|
#endif
|
|
|
|
#endif /* __MWERKS__ */
|
|
|
|
|
1992-08-17 08:55:12 +00:00
|
|
|
typedef struct { char c; short x; } s_short;
|
|
|
|
typedef struct { char c; int x; } s_int;
|
|
|
|
typedef struct { char c; long x; } s_long;
|
|
|
|
typedef struct { char c; float x; } s_float;
|
|
|
|
typedef struct { char c; double x; } s_double;
|
|
|
|
|
|
|
|
#define SHORT_ALIGN (sizeof(s_short) - sizeof(short))
|
|
|
|
#define INT_ALIGN (sizeof(s_int) - sizeof(int))
|
|
|
|
#define LONG_ALIGN (sizeof(s_long) - sizeof(long))
|
|
|
|
#define FLOAT_ALIGN (sizeof(s_float) - sizeof(float))
|
|
|
|
#define DOUBLE_ALIGN (sizeof(s_double) - sizeof(double))
|
|
|
|
|
1995-02-02 14:29:10 +00:00
|
|
|
#ifdef __powerc
|
|
|
|
#pragma options align=reset
|
|
|
|
#endif
|
|
|
|
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
/* Helper routine to get a Python integer and raise the appropriate error
|
|
|
|
if it isn't one */
|
1992-08-17 08:55:12 +00:00
|
|
|
|
|
|
|
static int
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
get_long(v, p)
|
|
|
|
PyObject *v;
|
|
|
|
long *p;
|
|
|
|
{
|
|
|
|
long x = PyInt_AsLong(v);
|
|
|
|
if (x == -1 && PyErr_Occurred()) {
|
|
|
|
if (PyErr_Occurred() == PyExc_TypeError)
|
|
|
|
PyErr_SetString(StructError,
|
|
|
|
"required argument is not an integer");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
*p = x;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
1996-12-31 16:29:52 +00:00
|
|
|
/* Same, but handling unsigned long */
|
|
|
|
|
|
|
|
static int
|
|
|
|
get_ulong(v, p)
|
|
|
|
PyObject *v;
|
|
|
|
unsigned long *p;
|
|
|
|
{
|
1997-01-03 19:08:16 +00:00
|
|
|
if (PyLong_Check(v)) {
|
|
|
|
unsigned long x = PyLong_AsUnsignedLong(v);
|
|
|
|
if (x == (unsigned long)(-1) && PyErr_Occurred())
|
1996-12-31 16:29:52 +00:00
|
|
|
return -1;
|
1997-01-03 19:08:16 +00:00
|
|
|
*p = x;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
return get_long(v, (long *)p);
|
1996-12-31 16:29:52 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-01-02 22:21:36 +00:00
|
|
|
/* Floating point helpers */
|
|
|
|
|
|
|
|
/* These use ANSI/IEEE Standard 754-1985 (Standard for Binary Floating
|
|
|
|
Point Arithmetic). See the following URL:
|
|
|
|
http://www.psc.edu/general/software/packages/ieee/ieee.html */
|
|
|
|
|
1997-01-02 23:23:20 +00:00
|
|
|
/* XXX Inf/NaN are not handled quite right (but underflow is!) */
|
1997-01-02 22:21:36 +00:00
|
|
|
|
|
|
|
static int
|
|
|
|
pack_float(x, p, incr)
|
|
|
|
double x; /* The number to pack */
|
|
|
|
char *p; /* Where to pack the high order byte */
|
|
|
|
int incr; /* 1 for big-endian; -1 for little-endian */
|
|
|
|
{
|
|
|
|
int s;
|
|
|
|
int e;
|
1997-01-02 23:23:20 +00:00
|
|
|
double f;
|
|
|
|
long fbits;
|
1997-01-02 22:21:36 +00:00
|
|
|
|
|
|
|
if (x < 0) {
|
|
|
|
s = 1;
|
|
|
|
x = -x;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
s = 0;
|
1997-01-02 23:23:20 +00:00
|
|
|
|
|
|
|
f = frexp(x, &e);
|
|
|
|
|
|
|
|
/* Normalize f to be in the range [1.0, 2.0) */
|
|
|
|
if (0.5 <= f && f < 1.0) {
|
|
|
|
f *= 2.0;
|
1997-01-02 22:21:36 +00:00
|
|
|
e--;
|
|
|
|
}
|
1997-01-02 23:23:20 +00:00
|
|
|
else if (f == 0.0) {
|
1997-01-02 22:21:36 +00:00
|
|
|
e = 0;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
PyErr_SetString(PyExc_SystemError,
|
|
|
|
"frexp() result out of range");
|
|
|
|
return -1;
|
|
|
|
}
|
1997-01-02 23:23:20 +00:00
|
|
|
|
|
|
|
if (e >= 128) {
|
|
|
|
/* XXX 128 itself is reserved for Inf/NaN */
|
1997-01-02 22:21:36 +00:00
|
|
|
PyErr_SetString(PyExc_OverflowError,
|
|
|
|
"float too large to pack with f format");
|
|
|
|
return -1;
|
|
|
|
}
|
1997-01-02 23:23:20 +00:00
|
|
|
else if (e < -126) {
|
|
|
|
/* Gradual underflow */
|
|
|
|
f = ldexp(f, 126 + e);
|
1997-01-02 22:21:36 +00:00
|
|
|
e = 0;
|
|
|
|
}
|
|
|
|
else {
|
1997-01-02 23:23:20 +00:00
|
|
|
e += 127;
|
|
|
|
f -= 1.0; /* Get rid of leading 1 */
|
1997-01-02 22:21:36 +00:00
|
|
|
}
|
|
|
|
|
1997-01-02 23:23:20 +00:00
|
|
|
f *= 8388608.0; /* 2**23 */
|
|
|
|
fbits = (long) floor(f + 0.5); /* Round */
|
|
|
|
|
1997-01-02 22:21:36 +00:00
|
|
|
/* First byte */
|
|
|
|
*p = (s<<7) | (e>>1);
|
|
|
|
p += incr;
|
|
|
|
|
|
|
|
/* Second byte */
|
1997-04-11 20:44:04 +00:00
|
|
|
*p = (char) (((e&1)<<7) | (fbits>>16));
|
1997-01-02 22:21:36 +00:00
|
|
|
p += incr;
|
|
|
|
|
|
|
|
/* Third byte */
|
1997-01-02 23:23:20 +00:00
|
|
|
*p = (fbits>>8) & 0xFF;
|
1997-01-02 22:21:36 +00:00
|
|
|
p += incr;
|
|
|
|
|
|
|
|
/* Fourth byte */
|
1997-01-02 23:23:20 +00:00
|
|
|
*p = fbits&0xFF;
|
1997-01-02 22:21:36 +00:00
|
|
|
|
|
|
|
/* Done */
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
pack_double(x, p, incr)
|
|
|
|
double x; /* The number to pack */
|
|
|
|
char *p; /* Where to pack the high order byte */
|
|
|
|
int incr; /* 1 for big-endian; -1 for little-endian */
|
|
|
|
{
|
|
|
|
int s;
|
|
|
|
int e;
|
1997-01-02 23:23:20 +00:00
|
|
|
double f;
|
1997-01-02 22:21:36 +00:00
|
|
|
long fhi, flo;
|
|
|
|
|
|
|
|
if (x < 0) {
|
|
|
|
s = 1;
|
|
|
|
x = -x;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
s = 0;
|
1997-01-02 23:23:20 +00:00
|
|
|
|
|
|
|
f = frexp(x, &e);
|
|
|
|
|
|
|
|
/* Normalize f to be in the range [1.0, 2.0) */
|
|
|
|
if (0.5 <= f && f < 1.0) {
|
|
|
|
f *= 2.0;
|
1997-01-02 22:21:36 +00:00
|
|
|
e--;
|
|
|
|
}
|
1997-01-02 23:23:20 +00:00
|
|
|
else if (f == 0.0) {
|
1997-01-02 22:21:36 +00:00
|
|
|
e = 0;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
PyErr_SetString(PyExc_SystemError,
|
|
|
|
"frexp() result out of range");
|
|
|
|
return -1;
|
|
|
|
}
|
1997-01-02 23:23:20 +00:00
|
|
|
|
|
|
|
if (e >= 1024) {
|
|
|
|
/* XXX 1024 itself is reserved for Inf/NaN */
|
1997-01-02 22:21:36 +00:00
|
|
|
PyErr_SetString(PyExc_OverflowError,
|
|
|
|
"float too large to pack with d format");
|
|
|
|
return -1;
|
|
|
|
}
|
1997-01-02 23:23:20 +00:00
|
|
|
else if (e < -1022) {
|
|
|
|
/* Gradual underflow */
|
|
|
|
f = ldexp(f, 1022 + e);
|
1997-01-02 22:21:36 +00:00
|
|
|
e = 0;
|
|
|
|
}
|
|
|
|
else {
|
1997-01-02 23:23:20 +00:00
|
|
|
e += 1023;
|
|
|
|
f -= 1.0; /* Get rid of leading 1 */
|
1997-01-02 22:21:36 +00:00
|
|
|
}
|
|
|
|
|
1997-01-02 23:23:20 +00:00
|
|
|
/* fhi receives the high 28 bits; flo the low 24 bits (== 52 bits) */
|
|
|
|
f *= 268435456.0; /* 2**28 */
|
|
|
|
fhi = (long) floor(f); /* Truncate */
|
|
|
|
f -= (double)fhi;
|
|
|
|
f *= 16777216.0; /* 2**24 */
|
|
|
|
flo = (long) floor(f + 0.5); /* Round */
|
|
|
|
|
1997-01-02 22:21:36 +00:00
|
|
|
/* First byte */
|
|
|
|
*p = (s<<7) | (e>>4);
|
|
|
|
p += incr;
|
|
|
|
|
|
|
|
/* Second byte */
|
1997-04-11 20:44:04 +00:00
|
|
|
*p = (char) (((e&0xF)<<4) | (fhi>>24));
|
1997-01-02 22:21:36 +00:00
|
|
|
p += incr;
|
|
|
|
|
|
|
|
/* Third byte */
|
|
|
|
*p = (fhi>>16) & 0xFF;
|
|
|
|
p += incr;
|
|
|
|
|
|
|
|
/* Fourth byte */
|
|
|
|
*p = (fhi>>8) & 0xFF;
|
|
|
|
p += incr;
|
|
|
|
|
|
|
|
/* Fifth byte */
|
|
|
|
*p = fhi & 0xFF;
|
|
|
|
p += incr;
|
|
|
|
|
|
|
|
/* Sixth byte */
|
|
|
|
*p = (flo>>16) & 0xFF;
|
|
|
|
p += incr;
|
|
|
|
|
|
|
|
/* Seventh byte */
|
|
|
|
*p = (flo>>8) & 0xFF;
|
|
|
|
p += incr;
|
|
|
|
|
|
|
|
/* Eighth byte */
|
|
|
|
*p = flo & 0xFF;
|
|
|
|
p += incr;
|
|
|
|
|
|
|
|
/* Done */
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
unpack_float(p, incr)
|
|
|
|
char *p; /* Where the high order byte is */
|
|
|
|
int incr; /* 1 for big-endian; -1 for little-endian */
|
|
|
|
{
|
|
|
|
int s;
|
|
|
|
int e;
|
|
|
|
long f;
|
|
|
|
double x;
|
|
|
|
|
|
|
|
/* First byte */
|
|
|
|
s = (*p>>7) & 1;
|
|
|
|
e = (*p & 0x7F) << 1;
|
|
|
|
p += incr;
|
|
|
|
|
|
|
|
/* Second byte */
|
|
|
|
e |= (*p>>7) & 1;
|
|
|
|
f = (*p & 0x7F) << 16;
|
|
|
|
p += incr;
|
|
|
|
|
|
|
|
/* Third byte */
|
|
|
|
f |= (*p & 0xFF) << 8;
|
|
|
|
p += incr;
|
|
|
|
|
|
|
|
/* Fourth byte */
|
|
|
|
f |= *p & 0xFF;
|
|
|
|
|
|
|
|
x = (double)f / 8388608.0;
|
|
|
|
|
|
|
|
/* XXX This sadly ignores Inf/NaN issues */
|
1997-01-02 22:31:07 +00:00
|
|
|
if (e == 0)
|
|
|
|
e = -126;
|
|
|
|
else {
|
|
|
|
x += 1.0;
|
|
|
|
e -= 127;
|
|
|
|
}
|
|
|
|
x = ldexp(x, e);
|
1997-01-02 22:21:36 +00:00
|
|
|
|
|
|
|
if (s)
|
|
|
|
x = -x;
|
|
|
|
|
|
|
|
return PyFloat_FromDouble(x);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
unpack_double(p, incr)
|
|
|
|
char *p; /* Where the high order byte is */
|
|
|
|
int incr; /* 1 for big-endian; -1 for little-endian */
|
|
|
|
{
|
|
|
|
int s;
|
|
|
|
int e;
|
|
|
|
long fhi, flo;
|
|
|
|
double x;
|
|
|
|
|
|
|
|
/* First byte */
|
|
|
|
s = (*p>>7) & 1;
|
|
|
|
e = (*p & 0x7F) << 4;
|
|
|
|
p += incr;
|
|
|
|
|
|
|
|
/* Second byte */
|
|
|
|
e |= (*p>>4) & 0xF;
|
|
|
|
fhi = (*p & 0xF) << 24;
|
|
|
|
p += incr;
|
|
|
|
|
|
|
|
/* Third byte */
|
|
|
|
fhi |= (*p & 0xFF) << 16;
|
|
|
|
p += incr;
|
|
|
|
|
|
|
|
/* Fourth byte */
|
|
|
|
fhi |= (*p & 0xFF) << 8;
|
|
|
|
p += incr;
|
|
|
|
|
|
|
|
/* Fifth byte */
|
|
|
|
fhi |= *p & 0xFF;
|
|
|
|
p += incr;
|
|
|
|
|
|
|
|
/* Sixth byte */
|
|
|
|
flo = (*p & 0xFF) << 16;
|
|
|
|
p += incr;
|
|
|
|
|
|
|
|
/* Seventh byte */
|
|
|
|
flo |= (*p & 0xFF) << 8;
|
|
|
|
p += incr;
|
|
|
|
|
|
|
|
/* Eighth byte */
|
|
|
|
flo |= *p & 0xFF;
|
|
|
|
p += incr;
|
|
|
|
|
|
|
|
x = (double)fhi + (double)flo / 16777216.0; /* 2**24 */
|
|
|
|
x /= 268435456.0; /* 2**28 */
|
|
|
|
|
|
|
|
/* XXX This sadly ignores Inf/NaN */
|
1997-01-02 22:31:07 +00:00
|
|
|
if (e == 0)
|
|
|
|
e = -1022;
|
|
|
|
else {
|
|
|
|
x += 1.0;
|
|
|
|
e -= 1023;
|
|
|
|
}
|
|
|
|
x = ldexp(x, e);
|
1997-01-02 22:21:36 +00:00
|
|
|
|
|
|
|
if (s)
|
|
|
|
x = -x;
|
|
|
|
|
|
|
|
return PyFloat_FromDouble(x);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
/* The translation function for each format character is table driven */
|
|
|
|
|
|
|
|
typedef struct _formatdef {
|
|
|
|
char format;
|
1992-08-17 08:55:12 +00:00
|
|
|
int size;
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
int alignment;
|
|
|
|
PyObject* (*unpack) Py_PROTO((const char *,
|
|
|
|
const struct _formatdef *));
|
|
|
|
int (*pack) Py_PROTO((char *,
|
|
|
|
PyObject *,
|
|
|
|
const struct _formatdef *));
|
|
|
|
} formatdef;
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
nu_char(p, f)
|
|
|
|
const char *p;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
return PyString_FromStringAndSize(p, 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
nu_byte(p, f)
|
|
|
|
const char *p;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
return PyInt_FromLong((long) *(signed char *)p);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
nu_ubyte(p, f)
|
|
|
|
const char *p;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
return PyInt_FromLong((long) *(unsigned char *)p);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
nu_short(p, f)
|
|
|
|
const char *p;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
return PyInt_FromLong((long) *(short *)p);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
nu_ushort(p, f)
|
|
|
|
const char *p;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
return PyInt_FromLong((long) *(unsigned short *)p);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
nu_int(p, f)
|
|
|
|
const char *p;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
return PyInt_FromLong((long) *(int *)p);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
nu_uint(p, f)
|
|
|
|
const char *p;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
unsigned int x = *(unsigned int *)p;
|
1997-01-03 19:08:16 +00:00
|
|
|
return PyLong_FromUnsignedLong((unsigned long)x);
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
nu_long(p, f)
|
|
|
|
const char *p;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
return PyInt_FromLong(*(long *)p);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
nu_ulong(p, f)
|
|
|
|
const char *p;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
1997-01-03 19:08:16 +00:00
|
|
|
return PyLong_FromUnsignedLong(*(unsigned long *)p);
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
nu_float(p, f)
|
|
|
|
const char *p;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
float x;
|
|
|
|
memcpy((char *)&x, p, sizeof(float));
|
|
|
|
return PyFloat_FromDouble((double)x);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
nu_double(p, f)
|
|
|
|
const char *p;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
double x;
|
|
|
|
memcpy((char *)&x, p, sizeof(double));
|
|
|
|
return PyFloat_FromDouble(x);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
np_byte(p, v, f)
|
|
|
|
char *p;
|
|
|
|
PyObject *v;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
long x;
|
|
|
|
if (get_long(v, &x) < 0)
|
|
|
|
return -1;
|
1997-04-11 20:44:04 +00:00
|
|
|
*p = (char)x;
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
np_char(p, v, f)
|
|
|
|
char *p;
|
|
|
|
PyObject *v;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
if (!PyString_Check(v) || PyString_Size(v) != 1) {
|
|
|
|
PyErr_SetString(StructError,
|
|
|
|
"char format require string of length 1");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
*p = *PyString_AsString(v);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
np_short(p, v, f)
|
|
|
|
char *p;
|
|
|
|
PyObject *v;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
long x;
|
|
|
|
if (get_long(v, &x) < 0)
|
|
|
|
return -1;
|
1997-04-11 20:44:04 +00:00
|
|
|
* (short *)p = (short)x;
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
np_int(p, v, f)
|
|
|
|
char *p;
|
|
|
|
PyObject *v;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
long x;
|
|
|
|
if (get_long(v, &x) < 0)
|
|
|
|
return -1;
|
|
|
|
* (int *)p = x;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
1996-12-31 16:29:52 +00:00
|
|
|
static int
|
|
|
|
np_uint(p, v, f)
|
|
|
|
char *p;
|
|
|
|
PyObject *v;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
unsigned long x;
|
|
|
|
if (get_ulong(v, &x) < 0)
|
|
|
|
return -1;
|
|
|
|
* (unsigned int *)p = x;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
static int
|
|
|
|
np_long(p, v, f)
|
|
|
|
char *p;
|
|
|
|
PyObject *v;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
long x;
|
|
|
|
if (get_long(v, &x) < 0)
|
|
|
|
return -1;
|
|
|
|
* (long *)p = x;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
1996-12-31 16:29:52 +00:00
|
|
|
static int
|
|
|
|
np_ulong(p, v, f)
|
|
|
|
char *p;
|
|
|
|
PyObject *v;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
unsigned long x;
|
|
|
|
if (get_ulong(v, &x) < 0)
|
|
|
|
return -1;
|
|
|
|
* (unsigned long *)p = x;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
static int
|
|
|
|
np_float(p, v, f)
|
|
|
|
char *p;
|
|
|
|
PyObject *v;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
float x = (float)PyFloat_AsDouble(v);
|
|
|
|
if (x == -1 && PyErr_Occurred()) {
|
|
|
|
PyErr_SetString(StructError,
|
|
|
|
"required argument is not a float");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
memcpy(p, (char *)&x, sizeof(float));
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
np_double(p, v, f)
|
|
|
|
char *p;
|
|
|
|
PyObject *v;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
double x = PyFloat_AsDouble(v);
|
|
|
|
if (x == -1 && PyErr_Occurred()) {
|
|
|
|
PyErr_SetString(StructError,
|
|
|
|
"required argument is not a float");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
memcpy(p, (char *)&x, sizeof(double));
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static formatdef native_table[] = {
|
|
|
|
{'x', sizeof(char), 0, NULL},
|
|
|
|
{'b', sizeof(char), 0, nu_byte, np_byte},
|
|
|
|
{'B', sizeof(char), 0, nu_ubyte, np_byte},
|
|
|
|
{'c', sizeof(char), 0, nu_char, np_char},
|
|
|
|
{'s', sizeof(char), 0, NULL},
|
|
|
|
{'h', sizeof(short), SHORT_ALIGN, nu_short, np_short},
|
|
|
|
{'H', sizeof(short), SHORT_ALIGN, nu_ushort, np_short},
|
|
|
|
{'i', sizeof(int), INT_ALIGN, nu_int, np_int},
|
1996-12-31 16:29:52 +00:00
|
|
|
{'I', sizeof(int), INT_ALIGN, nu_uint, np_uint},
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
{'l', sizeof(long), LONG_ALIGN, nu_long, np_long},
|
1996-12-31 16:29:52 +00:00
|
|
|
{'L', sizeof(long), LONG_ALIGN, nu_ulong, np_ulong},
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
{'f', sizeof(float), FLOAT_ALIGN, nu_float, np_float},
|
|
|
|
{'d', sizeof(double), DOUBLE_ALIGN, nu_double, np_double},
|
|
|
|
{0}
|
|
|
|
};
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
bu_int(p, f)
|
|
|
|
const char *p;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
long x = 0;
|
|
|
|
int i = f->size;
|
|
|
|
do {
|
|
|
|
x = (x<<8) | (*p++ & 0xFF);
|
|
|
|
} while (--i > 0);
|
|
|
|
i = 8*(sizeof(long) - f->size);
|
|
|
|
if (i) {
|
|
|
|
x <<= i;
|
|
|
|
x >>= i;
|
|
|
|
}
|
|
|
|
return PyInt_FromLong(x);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
bu_uint(p, f)
|
|
|
|
const char *p;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
1997-01-03 19:08:16 +00:00
|
|
|
unsigned long x = 0;
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
int i = f->size;
|
|
|
|
do {
|
|
|
|
x = (x<<8) | (*p++ & 0xFF);
|
|
|
|
} while (--i > 0);
|
1997-01-03 19:08:16 +00:00
|
|
|
return PyLong_FromUnsignedLong(x);
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
}
|
|
|
|
|
1997-01-02 22:21:36 +00:00
|
|
|
static PyObject *
|
|
|
|
bu_float(p, f)
|
|
|
|
const char *p;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
return unpack_float(p, 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
bu_double(p, f)
|
|
|
|
const char *p;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
return unpack_double(p, 1);
|
|
|
|
}
|
|
|
|
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
static int
|
|
|
|
bp_int(p, v, f)
|
|
|
|
char *p;
|
|
|
|
PyObject *v;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
long x;
|
|
|
|
int i;
|
|
|
|
if (get_long(v, &x) < 0)
|
|
|
|
return -1;
|
|
|
|
i = f->size;
|
|
|
|
do {
|
1997-04-11 20:44:04 +00:00
|
|
|
p[--i] = (char)x;
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
x >>= 8;
|
|
|
|
} while (i > 0);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
1996-12-31 16:29:52 +00:00
|
|
|
static int
|
|
|
|
bp_uint(p, v, f)
|
|
|
|
char *p;
|
|
|
|
PyObject *v;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
unsigned long x;
|
|
|
|
int i;
|
|
|
|
if (get_ulong(v, &x) < 0)
|
|
|
|
return -1;
|
|
|
|
i = f->size;
|
|
|
|
do {
|
1997-04-11 20:44:04 +00:00
|
|
|
p[--i] = (char)x;
|
1996-12-31 16:29:52 +00:00
|
|
|
x >>= 8;
|
|
|
|
} while (i > 0);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
1997-01-02 22:21:36 +00:00
|
|
|
static int
|
|
|
|
bp_float(p, v, f)
|
|
|
|
char *p;
|
|
|
|
PyObject *v;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
double x = PyFloat_AsDouble(v);
|
|
|
|
if (x == -1 && PyErr_Occurred()) {
|
|
|
|
PyErr_SetString(StructError,
|
|
|
|
"required argument is not a float");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return pack_float(x, p, 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
bp_double(p, v, f)
|
|
|
|
char *p;
|
|
|
|
PyObject *v;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
double x = PyFloat_AsDouble(v);
|
|
|
|
if (x == -1 && PyErr_Occurred()) {
|
|
|
|
PyErr_SetString(StructError,
|
|
|
|
"required argument is not a float");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return pack_double(x, p, 1);
|
|
|
|
}
|
|
|
|
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
static formatdef bigendian_table[] = {
|
|
|
|
{'x', 1, 0, NULL},
|
|
|
|
{'b', 1, 0, bu_int, bp_int},
|
|
|
|
{'B', 1, 0, bu_uint, bp_int},
|
|
|
|
{'c', 1, 0, nu_char, np_char},
|
|
|
|
{'s', 1, 0, NULL},
|
|
|
|
{'h', 2, 0, bu_int, bp_int},
|
1996-12-31 16:29:52 +00:00
|
|
|
{'H', 2, 0, bu_uint, bp_uint},
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
{'i', 4, 0, bu_int, bp_int},
|
1996-12-31 16:29:52 +00:00
|
|
|
{'I', 4, 0, bu_uint, bp_uint},
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
{'l', 4, 0, bu_int, bp_int},
|
1996-12-31 16:29:52 +00:00
|
|
|
{'L', 4, 0, bu_uint, bp_uint},
|
1997-01-02 22:21:36 +00:00
|
|
|
{'f', 4, 0, bu_float, bp_float},
|
|
|
|
{'d', 8, 0, bu_double, bp_double},
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
{0}
|
|
|
|
};
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
lu_int(p, f)
|
|
|
|
const char *p;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
long x = 0;
|
|
|
|
int i = f->size;
|
|
|
|
do {
|
|
|
|
x = (x<<8) | (p[--i] & 0xFF);
|
|
|
|
} while (i > 0);
|
|
|
|
i = 8*(sizeof(long) - f->size);
|
|
|
|
if (i) {
|
|
|
|
x <<= i;
|
|
|
|
x >>= i;
|
|
|
|
}
|
|
|
|
return PyInt_FromLong(x);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
lu_uint(p, f)
|
|
|
|
const char *p;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
1997-01-03 19:08:16 +00:00
|
|
|
unsigned long x = 0;
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
int i = f->size;
|
|
|
|
do {
|
|
|
|
x = (x<<8) | (p[--i] & 0xFF);
|
|
|
|
} while (i > 0);
|
1997-01-03 19:08:16 +00:00
|
|
|
return PyLong_FromUnsignedLong(x);
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
}
|
|
|
|
|
1997-01-02 22:21:36 +00:00
|
|
|
static PyObject *
|
|
|
|
lu_float(p, f)
|
|
|
|
const char *p;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
return unpack_float(p+3, -1);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
lu_double(p, f)
|
|
|
|
const char *p;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
return unpack_double(p+7, -1);
|
|
|
|
}
|
|
|
|
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
static int
|
|
|
|
lp_int(p, v, f)
|
|
|
|
char *p;
|
|
|
|
PyObject *v;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
long x;
|
|
|
|
int i;
|
|
|
|
if (get_long(v, &x) < 0)
|
|
|
|
return -1;
|
|
|
|
i = f->size;
|
|
|
|
do {
|
1997-04-11 20:44:04 +00:00
|
|
|
*p++ = (char)x;
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
x >>= 8;
|
|
|
|
} while (--i > 0);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
1996-12-31 16:29:52 +00:00
|
|
|
static int
|
|
|
|
lp_uint(p, v, f)
|
|
|
|
char *p;
|
|
|
|
PyObject *v;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
unsigned long x;
|
|
|
|
int i;
|
|
|
|
if (get_ulong(v, &x) < 0)
|
|
|
|
return -1;
|
|
|
|
i = f->size;
|
|
|
|
do {
|
1997-04-11 20:44:04 +00:00
|
|
|
*p++ = (char)x;
|
1996-12-31 16:29:52 +00:00
|
|
|
x >>= 8;
|
|
|
|
} while (--i > 0);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
1997-01-02 22:21:36 +00:00
|
|
|
static int
|
|
|
|
lp_float(p, v, f)
|
|
|
|
char *p;
|
|
|
|
PyObject *v;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
double x = PyFloat_AsDouble(v);
|
|
|
|
if (x == -1 && PyErr_Occurred()) {
|
|
|
|
PyErr_SetString(StructError,
|
|
|
|
"required argument is not a float");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return pack_float(x, p+3, -1);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
lp_double(p, v, f)
|
|
|
|
char *p;
|
|
|
|
PyObject *v;
|
|
|
|
const formatdef *f;
|
|
|
|
{
|
|
|
|
double x = PyFloat_AsDouble(v);
|
|
|
|
if (x == -1 && PyErr_Occurred()) {
|
|
|
|
PyErr_SetString(StructError,
|
|
|
|
"required argument is not a float");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return pack_double(x, p+7, -1);
|
|
|
|
}
|
|
|
|
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
static formatdef lilendian_table[] = {
|
|
|
|
{'x', 1, 0, NULL},
|
|
|
|
{'b', 1, 0, lu_int, lp_int},
|
|
|
|
{'B', 1, 0, lu_uint, lp_int},
|
|
|
|
{'c', 1, 0, nu_char, np_char},
|
|
|
|
{'s', 1, 0, NULL},
|
|
|
|
{'h', 2, 0, lu_int, lp_int},
|
1996-12-31 16:29:52 +00:00
|
|
|
{'H', 2, 0, lu_uint, lp_uint},
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
{'i', 4, 0, lu_int, lp_int},
|
1996-12-31 16:29:52 +00:00
|
|
|
{'I', 4, 0, lu_uint, lp_uint},
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
{'l', 4, 0, lu_int, lp_int},
|
1996-12-31 16:29:52 +00:00
|
|
|
{'L', 4, 0, lu_uint, lp_uint},
|
1997-01-02 22:21:36 +00:00
|
|
|
{'f', 4, 0, lu_float, lp_float},
|
|
|
|
{'d', 8, 0, lu_double, lp_double},
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
{0}
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
static const formatdef *
|
|
|
|
whichtable(pfmt)
|
|
|
|
const char **pfmt;
|
|
|
|
{
|
|
|
|
const char *fmt = (*pfmt)++; /* May be backed out of later */
|
|
|
|
switch (*fmt) {
|
|
|
|
case '<':
|
|
|
|
return lilendian_table;
|
|
|
|
case '>':
|
|
|
|
case '!': /* Network byte order is big-endian */
|
|
|
|
return bigendian_table;
|
|
|
|
case '=': { /* Host byte order -- different from native in aligment! */
|
|
|
|
int n = 1;
|
|
|
|
char *p = (char *) &n;
|
|
|
|
if (*p == 1)
|
|
|
|
return lilendian_table;
|
|
|
|
else
|
|
|
|
return bigendian_table;
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
--*pfmt; /* Back out of pointer increment */
|
|
|
|
/* Fall through */
|
|
|
|
case '@':
|
|
|
|
return native_table;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* Get the table entry for a format code */
|
|
|
|
|
|
|
|
static const formatdef *
|
|
|
|
getentry(c, f)
|
1992-08-17 08:55:12 +00:00
|
|
|
int c;
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
const formatdef *f;
|
1992-08-17 08:55:12 +00:00
|
|
|
{
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
for (; f->format != '\0'; f++) {
|
|
|
|
if (f->format == c) {
|
|
|
|
return f;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
PyErr_SetString(StructError, "bad char in struct format");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* Align a size according to a format code */
|
1992-08-17 08:55:12 +00:00
|
|
|
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
static int
|
|
|
|
align(size, c, e)
|
|
|
|
int size;
|
|
|
|
int c;
|
|
|
|
const formatdef *e;
|
|
|
|
{
|
|
|
|
if (e->format == c) {
|
|
|
|
if (e->alignment) {
|
|
|
|
size = ((size + e->alignment - 1)
|
|
|
|
/ e->alignment)
|
|
|
|
* e->alignment;
|
|
|
|
}
|
1992-08-17 08:55:12 +00:00
|
|
|
}
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
return size;
|
1992-08-17 08:55:12 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* calculate the size of a format string */
|
|
|
|
|
|
|
|
static int
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
calcsize(fmt, f)
|
|
|
|
const char *fmt;
|
|
|
|
const formatdef *f;
|
1992-08-17 08:55:12 +00:00
|
|
|
{
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
const formatdef *e;
|
|
|
|
const char *s;
|
1992-08-17 08:55:12 +00:00
|
|
|
char c;
|
|
|
|
int size, num, itemsize, x;
|
|
|
|
|
|
|
|
s = fmt;
|
|
|
|
size = 0;
|
|
|
|
while ((c = *s++) != '\0') {
|
|
|
|
if ('0' <= c && c <= '9') {
|
|
|
|
num = c - '0';
|
|
|
|
while ('0' <= (c = *s++) && c <= '9') {
|
|
|
|
x = num*10 + (c - '0');
|
|
|
|
if (x/10 != num) {
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
PyErr_SetString(
|
|
|
|
StructError,
|
|
|
|
"overflow in item count");
|
1992-08-17 08:55:12 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
num = x;
|
|
|
|
}
|
|
|
|
if (c == '\0')
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
num = 1;
|
|
|
|
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
e = getentry(c, f);
|
|
|
|
if (e == NULL)
|
1992-08-17 08:55:12 +00:00
|
|
|
return -1;
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
itemsize = e->size;
|
|
|
|
size = align(size, c, e);
|
1992-08-17 08:55:12 +00:00
|
|
|
x = num * itemsize;
|
|
|
|
size += x;
|
|
|
|
if (x/itemsize != num || size < 0) {
|
1996-12-12 23:32:31 +00:00
|
|
|
PyErr_SetString(StructError,
|
|
|
|
"total struct size too long");
|
1992-08-17 08:55:12 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return size;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* pack(fmt, v1, v2, ...) --> string */
|
|
|
|
|
1996-12-12 23:32:31 +00:00
|
|
|
static PyObject *
|
1992-08-17 08:55:12 +00:00
|
|
|
struct_calcsize(self, args)
|
1996-12-12 23:32:31 +00:00
|
|
|
PyObject *self; /* Not used */
|
|
|
|
PyObject *args;
|
1992-08-17 08:55:12 +00:00
|
|
|
{
|
|
|
|
char *fmt;
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
const formatdef *f;
|
1992-08-17 08:55:12 +00:00
|
|
|
int size;
|
|
|
|
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
if (!PyArg_ParseTuple(args, "s", &fmt))
|
1992-08-17 08:55:12 +00:00
|
|
|
return NULL;
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
f = whichtable(&fmt);
|
|
|
|
size = calcsize(fmt, f);
|
1992-08-17 08:55:12 +00:00
|
|
|
if (size < 0)
|
|
|
|
return NULL;
|
1996-12-12 23:32:31 +00:00
|
|
|
return PyInt_FromLong((long)size);
|
1992-08-17 08:55:12 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* pack(fmt, v1, v2, ...) --> string */
|
|
|
|
|
1996-12-12 23:32:31 +00:00
|
|
|
static PyObject *
|
1992-08-17 08:55:12 +00:00
|
|
|
struct_pack(self, args)
|
1996-12-12 23:32:31 +00:00
|
|
|
PyObject *self; /* Not used */
|
|
|
|
PyObject *args;
|
1992-08-17 08:55:12 +00:00
|
|
|
{
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
const formatdef *f, *e;
|
1996-12-12 23:32:31 +00:00
|
|
|
PyObject *format, *result, *v;
|
1992-08-17 08:55:12 +00:00
|
|
|
char *fmt;
|
|
|
|
int size, num;
|
|
|
|
int i, n;
|
1997-01-03 15:40:33 +00:00
|
|
|
char *s, *res, *restart, *nres;
|
1992-08-17 08:55:12 +00:00
|
|
|
char c;
|
|
|
|
|
1996-12-12 23:32:31 +00:00
|
|
|
if (args == NULL || !PyTuple_Check(args) ||
|
|
|
|
(n = PyTuple_Size(args)) < 1)
|
|
|
|
{
|
|
|
|
PyErr_BadArgument();
|
1992-08-17 08:55:12 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
1996-12-12 23:32:31 +00:00
|
|
|
format = PyTuple_GetItem(args, 0);
|
|
|
|
if (!PyArg_Parse(format, "s", &fmt))
|
1992-08-17 08:55:12 +00:00
|
|
|
return NULL;
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
f = whichtable(&fmt);
|
|
|
|
size = calcsize(fmt, f);
|
1992-08-17 08:55:12 +00:00
|
|
|
if (size < 0)
|
|
|
|
return NULL;
|
1996-12-12 23:32:31 +00:00
|
|
|
result = PyString_FromStringAndSize((char *)NULL, size);
|
1992-08-17 08:55:12 +00:00
|
|
|
if (result == NULL)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
s = fmt;
|
|
|
|
i = 1;
|
1996-12-12 23:32:31 +00:00
|
|
|
res = restart = PyString_AsString(result);
|
1992-08-17 08:55:12 +00:00
|
|
|
|
|
|
|
while ((c = *s++) != '\0') {
|
|
|
|
if ('0' <= c && c <= '9') {
|
|
|
|
num = c - '0';
|
|
|
|
while ('0' <= (c = *s++) && c <= '9')
|
|
|
|
num = num*10 + (c - '0');
|
|
|
|
if (c == '\0')
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
num = 1;
|
|
|
|
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
e = getentry(c, f);
|
|
|
|
if (e == NULL)
|
|
|
|
goto fail;
|
1997-01-03 15:40:33 +00:00
|
|
|
nres = restart + align((int)(res-restart), c, e);
|
|
|
|
/* Fill padd bytes with zeros */
|
|
|
|
while (res < nres)
|
|
|
|
*res++ = '\0';
|
1996-12-31 02:10:45 +00:00
|
|
|
if (num == 0 && c != 's')
|
|
|
|
continue;
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
do {
|
|
|
|
if (c == 'x') {
|
|
|
|
/* doesn't consume arguments */
|
1996-12-31 02:10:45 +00:00
|
|
|
memset(res, '\0', num);
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
res += num;
|
1992-08-17 08:55:12 +00:00
|
|
|
break;
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
}
|
|
|
|
if (i >= n) {
|
|
|
|
PyErr_SetString(StructError,
|
|
|
|
"insufficient arguments to pack");
|
|
|
|
goto fail;
|
1992-08-17 08:55:12 +00:00
|
|
|
}
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
v = PyTuple_GetItem(args, i++);
|
|
|
|
if (v == NULL)
|
|
|
|
goto fail;
|
|
|
|
if (c == 's') {
|
|
|
|
/* num is string size, not repeat count */
|
|
|
|
int n;
|
|
|
|
if (!PyString_Check(v)) {
|
1996-12-12 23:32:31 +00:00
|
|
|
PyErr_SetString(StructError,
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
"argument for 's' must be a string");
|
1992-08-17 08:55:12 +00:00
|
|
|
goto fail;
|
|
|
|
}
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
n = PyString_Size(v);
|
|
|
|
if (n > num)
|
|
|
|
n = num;
|
|
|
|
if (n > 0)
|
|
|
|
memcpy(res, PyString_AsString(v), n);
|
|
|
|
if (n < num)
|
1996-12-31 02:10:45 +00:00
|
|
|
memset(res+n, '\0', num-n);
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
res += num;
|
1992-08-17 08:55:12 +00:00
|
|
|
break;
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
}
|
|
|
|
else {
|
|
|
|
if (e->pack(res, v, e) < 0)
|
1992-08-17 08:55:12 +00:00
|
|
|
goto fail;
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
res += e->size;
|
1992-08-17 08:55:12 +00:00
|
|
|
}
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
} while (--num > 0);
|
1992-08-17 08:55:12 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (i < n) {
|
1996-12-12 23:32:31 +00:00
|
|
|
PyErr_SetString(StructError,
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
"too many arguments for pack format");
|
1992-08-17 08:55:12 +00:00
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
return result;
|
|
|
|
|
|
|
|
fail:
|
1996-12-12 23:32:31 +00:00
|
|
|
Py_DECREF(result);
|
1992-08-17 08:55:12 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* unpack(fmt, string) --> (v1, v2, ...) */
|
|
|
|
|
1996-12-12 23:32:31 +00:00
|
|
|
static PyObject *
|
1992-08-17 08:55:12 +00:00
|
|
|
struct_unpack(self, args)
|
1996-12-12 23:32:31 +00:00
|
|
|
PyObject *self; /* Not used */
|
|
|
|
PyObject *args;
|
1992-08-17 08:55:12 +00:00
|
|
|
{
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
const formatdef *f, *e;
|
1992-08-17 08:55:12 +00:00
|
|
|
char *str, *start, *fmt, *s;
|
|
|
|
char c;
|
1997-01-03 00:26:28 +00:00
|
|
|
int len, size, num;
|
1996-12-12 23:32:31 +00:00
|
|
|
PyObject *res, *v;
|
1992-08-17 08:55:12 +00:00
|
|
|
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
if (!PyArg_ParseTuple(args, "ss#", &fmt, &start, &len))
|
|
|
|
return NULL;
|
|
|
|
f = whichtable(&fmt);
|
|
|
|
size = calcsize(fmt, f);
|
|
|
|
if (size < 0)
|
1992-08-17 08:55:12 +00:00
|
|
|
return NULL;
|
|
|
|
if (size != len) {
|
1996-12-12 23:32:31 +00:00
|
|
|
PyErr_SetString(StructError,
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
"unpack str size does not match format");
|
1992-08-17 08:55:12 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
1996-12-12 23:32:31 +00:00
|
|
|
res = PyList_New(0);
|
1992-08-17 08:55:12 +00:00
|
|
|
if (res == NULL)
|
|
|
|
return NULL;
|
|
|
|
str = start;
|
|
|
|
s = fmt;
|
|
|
|
while ((c = *s++) != '\0') {
|
|
|
|
if ('0' <= c && c <= '9') {
|
|
|
|
num = c - '0';
|
|
|
|
while ('0' <= (c = *s++) && c <= '9')
|
|
|
|
num = num*10 + (c - '0');
|
|
|
|
if (c == '\0')
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
num = 1;
|
|
|
|
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
e = getentry(c, f);
|
|
|
|
if (e == NULL)
|
|
|
|
goto fail;
|
|
|
|
str = start + align((int)(str-start), c, e);
|
1996-12-31 02:10:45 +00:00
|
|
|
if (num == 0 && c != 's')
|
|
|
|
continue;
|
1992-08-17 08:55:12 +00:00
|
|
|
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
do {
|
|
|
|
if (c == 'x') {
|
|
|
|
str += num;
|
1992-08-17 08:55:12 +00:00
|
|
|
break;
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
}
|
|
|
|
if (c == 's') {
|
|
|
|
/* num is string size, not repeat count */
|
|
|
|
v = PyString_FromStringAndSize(str, num);
|
|
|
|
if (v == NULL)
|
|
|
|
goto fail;
|
|
|
|
str += num;
|
|
|
|
num = 0;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
v = e->unpack(str, e);
|
|
|
|
if (v == NULL)
|
|
|
|
goto fail;
|
|
|
|
str += e->size;
|
1992-08-17 08:55:12 +00:00
|
|
|
}
|
1996-12-12 23:32:31 +00:00
|
|
|
if (v == NULL || PyList_Append(res, v) < 0)
|
1992-08-17 08:55:12 +00:00
|
|
|
goto fail;
|
1996-12-12 23:32:31 +00:00
|
|
|
Py_DECREF(v);
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
} while (--num > 0);
|
1992-08-17 08:55:12 +00:00
|
|
|
}
|
|
|
|
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
v = PyList_AsTuple(res);
|
|
|
|
Py_DECREF(res);
|
|
|
|
return v;
|
1992-08-17 08:55:12 +00:00
|
|
|
|
|
|
|
fail:
|
1996-12-12 23:32:31 +00:00
|
|
|
Py_DECREF(res);
|
1992-08-17 08:55:12 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
1992-08-19 16:44:15 +00:00
|
|
|
|
1992-08-17 08:55:12 +00:00
|
|
|
/* List of functions */
|
|
|
|
|
1996-12-12 23:32:31 +00:00
|
|
|
static PyMethodDef struct_methods[] = {
|
Pretty much rewritten to fulfull several long-standing wishes:
-- The whole implementation is now more table-driven.
-- Unsigned integers. Format characters 'B', 'H', 'I' and 'L'
mean unsigned byte, short, int and long. For 'I' and 'L', the return
value is a Python long integer if a Python plain integer can't
represent the required range (note: this is dependent on the size of
the relevant C types only, not of the sign of the actual value).
-- A new format character 's' packs/unpacks a string. When given a
count prefix, this is the size of the string, not a repeat count like
for the other format characters; e.g. '10s' means a single 10-byte
string, while '10c' means 10 characters. For packing, the string is
truncated or padded with null bytes as appropriate to make it fit.
For unpacking, the resulting string always has exactly the specified
number of bytes. As a special case, '0s' means a single, empty
string (while '0c' means 0 characters).
-- Various byte order options. The first character of the format
string determines the byte order, size and alignment, as follows:
First character Byte order size and alignment
'@' native native
'=' native standard
'<' little-endian standard
'>' big-endian standard
'!' network (= big-endian) standard
If the first character is not one of these, '@' is assumed.
Native byte order is big-endian or little-endian, depending on the
host system (e.g. Motorola and Sun are big-endian; Intel and DEC are
little-endian).
Native size and alignment are determined using the C compiler's sizeof
expression. This is always combined with native byte order.
Standard size and alignment are as follows: no alignment is required
for any type (so you have to use pad bytes); short is 2 bytes; int and
long are 4 bytes. In this mode, there is no support for float and
double.
Note the difference between '@' and '=': both use native byte order,
but the size and alignment of the latter is standardized.
The form '!' is available for those poor souls who can't remember
whether network byte order is big-endian or little-endian.
There is no way to indicate non-native byte order (i.e. force
byte-swapping); use the appropriate choice of '<' or '>'.
1996-12-31 01:41:25 +00:00
|
|
|
{"calcsize", struct_calcsize, METH_VARARGS},
|
|
|
|
{"pack", struct_pack, METH_VARARGS},
|
|
|
|
{"unpack", struct_unpack, METH_VARARGS},
|
1992-08-17 08:55:12 +00:00
|
|
|
{NULL, NULL} /* sentinel */
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
/* Module initialization */
|
|
|
|
|
|
|
|
void
|
|
|
|
initstruct()
|
|
|
|
{
|
1996-12-12 23:32:31 +00:00
|
|
|
PyObject *m, *d;
|
1992-08-17 08:55:12 +00:00
|
|
|
|
|
|
|
/* Create the module and add the functions */
|
1996-12-12 23:32:31 +00:00
|
|
|
m = Py_InitModule("struct", struct_methods);
|
1992-08-17 08:55:12 +00:00
|
|
|
|
|
|
|
/* Add some symbolic constants to the module */
|
1996-12-12 23:32:31 +00:00
|
|
|
d = PyModule_GetDict(m);
|
|
|
|
StructError = PyString_FromString("struct.error");
|
|
|
|
PyDict_SetItemString(d, "error", StructError);
|
1992-08-17 08:55:12 +00:00
|
|
|
|
|
|
|
/* Check for errors */
|
1996-12-12 23:32:31 +00:00
|
|
|
if (PyErr_Occurred())
|
|
|
|
Py_FatalError("can't initialize module struct");
|
1992-08-17 08:55:12 +00:00
|
|
|
}
|