1992-08-17 16:55:12 +08: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 09:41:25 +08:00
|
|
|
/* New version supporting byte order, alignment and size options,
|
|
|
|
character strings, and unsigned numbers */
|
|
|
|
|
1997-12-19 12:24:24 +08:00
|
|
|
static char struct__doc__[] = "\
|
|
|
|
Functions to convert between Python values and C structs.\n\
|
|
|
|
Python strings are used to hold the data representing the C struct\n\
|
|
|
|
and also as format strings to describe the layout of data in the C struct.\n\
|
|
|
|
\n\
|
2001-06-12 00:45:33 +08:00
|
|
|
The optional first format char indicates byte order, size and alignment:\n\
|
|
|
|
@: native order, size & alignment (default)\n\
|
|
|
|
=: native order, std. size & alignment\n\
|
|
|
|
<: little-endian, std. size & alignment\n\
|
|
|
|
>: big-endian, std. size & alignment\n\
|
|
|
|
!: same as >\n\
|
1997-12-19 12:24:24 +08:00
|
|
|
\n\
|
|
|
|
The remaining chars indicate types of args and must match exactly;\n\
|
|
|
|
these can be preceded by a decimal repeat count:\n\
|
|
|
|
x: pad byte (no data); c:char; b:signed byte; B:unsigned byte;\n\
|
|
|
|
h:short; H:unsigned short; i:int; I:unsigned int;\n\
|
|
|
|
l:long; L:unsigned long; f:float; d:double.\n\
|
|
|
|
Special cases (preceding decimal count indicates length):\n\
|
2001-06-11 07:40:19 +08:00
|
|
|
s:string (array of char); p: pascal string (with count byte).\n\
|
1998-09-18 22:14:13 +08:00
|
|
|
Special case (only available in native format):\n\
|
|
|
|
P:an integer type that is wide enough to hold a pointer.\n\
|
2001-06-11 07:40:19 +08:00
|
|
|
Special case (not in native mode unless 'long long' in platform C):\n\
|
|
|
|
q:long long; Q:unsigned long long\n\
|
1997-12-19 12:24:24 +08:00
|
|
|
Whitespace between formats is ignored.\n\
|
|
|
|
\n\
|
|
|
|
The variable struct.error is an exception raised on errors.";
|
|
|
|
|
1996-12-13 07:32:31 +08:00
|
|
|
#include "Python.h"
|
1992-08-17 16:55:12 +08:00
|
|
|
|
1997-08-27 04:39:54 +08:00
|
|
|
#include <ctype.h>
|
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 09:41:25 +08:00
|
|
|
|
|
|
|
|
|
|
|
/* Exception */
|
|
|
|
|
1996-12-13 07:32:31 +08:00
|
|
|
static PyObject *StructError;
|
1992-08-17 16:55:12 +08:00
|
|
|
|
|
|
|
|
|
|
|
/* Define various structs to figure out the alignments of types */
|
|
|
|
|
1995-02-02 22:29:10 +08:00
|
|
|
#ifdef __MWERKS__
|
|
|
|
/*
|
|
|
|
** XXXX We have a problem here. There are no unique alignment rules
|
2001-06-12 00:57:33 +08:00
|
|
|
** on the PowerPC mac.
|
1995-02-02 22:29:10 +08:00
|
|
|
*/
|
|
|
|
#ifdef __powerc
|
|
|
|
#pragma options align=mac68k
|
|
|
|
#endif
|
|
|
|
#endif /* __MWERKS__ */
|
|
|
|
|
1992-08-17 16:55:12 +08: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;
|
1998-09-18 22:14:13 +08:00
|
|
|
typedef struct { char c; void *x; } s_void_p;
|
1992-08-17 16:55:12 +08:00
|
|
|
|
|
|
|
#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))
|
1998-09-18 22:14:13 +08:00
|
|
|
#define VOID_P_ALIGN (sizeof(s_void_p) - sizeof(void *))
|
1992-08-17 16:55:12 +08:00
|
|
|
|
2001-06-11 07:40:19 +08:00
|
|
|
/* We can't support q and Q in native mode unless the compiler does;
|
|
|
|
in std mode, they're 8 bytes on all platforms. */
|
|
|
|
#ifdef HAVE_LONG_LONG
|
|
|
|
typedef struct { char c; LONG_LONG x; } s_long_long;
|
|
|
|
#define LONG_LONG_ALIGN (sizeof(s_long_long) - sizeof(LONG_LONG))
|
|
|
|
#endif
|
|
|
|
|
2000-09-15 16:10:33 +08:00
|
|
|
#define STRINGIFY(x) #x
|
|
|
|
|
1995-02-02 22:29:10 +08:00
|
|
|
#ifdef __powerc
|
|
|
|
#pragma options align=reset
|
|
|
|
#endif
|
|
|
|
|
2001-06-12 09:22:22 +08:00
|
|
|
/* Helper to get a PyLongObject by hook or by crook. Caller should decref. */
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
get_pylong(PyObject *v)
|
|
|
|
{
|
|
|
|
PyNumberMethods *m;
|
|
|
|
|
|
|
|
assert(v != NULL);
|
|
|
|
if (PyInt_Check(v))
|
|
|
|
return PyLong_FromLong(PyInt_AS_LONG(v));
|
|
|
|
if (PyLong_Check(v)) {
|
|
|
|
Py_INCREF(v);
|
|
|
|
return v;
|
|
|
|
}
|
|
|
|
m = v->ob_type->tp_as_number;
|
|
|
|
if (m != NULL && m->nb_long != NULL) {
|
|
|
|
v = m->nb_long(v);
|
|
|
|
if (v == NULL)
|
|
|
|
return NULL;
|
|
|
|
if (PyLong_Check(v))
|
|
|
|
return v;
|
|
|
|
Py_DECREF(v);
|
|
|
|
}
|
|
|
|
PyErr_SetString(StructError,
|
|
|
|
"cannot convert argument to long");
|
|
|
|
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 09:41:25 +08:00
|
|
|
/* Helper routine to get a Python integer and raise the appropriate error
|
|
|
|
if it isn't one */
|
1992-08-17 16:55:12 +08:00
|
|
|
|
|
|
|
static int
|
2000-07-10 20:29:26 +08:00
|
|
|
get_long(PyObject *v, 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 09:41:25 +08:00
|
|
|
{
|
|
|
|
long x = PyInt_AsLong(v);
|
|
|
|
if (x == -1 && PyErr_Occurred()) {
|
1998-05-28 12:35:49 +08:00
|
|
|
if (PyErr_ExceptionMatches(PyExc_TypeError))
|
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 09:41:25 +08:00
|
|
|
PyErr_SetString(StructError,
|
|
|
|
"required argument is not an integer");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
*p = x;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-01-01 00:29:52 +08:00
|
|
|
/* Same, but handling unsigned long */
|
|
|
|
|
|
|
|
static int
|
2000-07-10 20:29:26 +08:00
|
|
|
get_ulong(PyObject *v, unsigned long *p)
|
1997-01-01 00:29:52 +08:00
|
|
|
{
|
1997-01-04 03:08:16 +08:00
|
|
|
if (PyLong_Check(v)) {
|
|
|
|
unsigned long x = PyLong_AsUnsignedLong(v);
|
|
|
|
if (x == (unsigned long)(-1) && PyErr_Occurred())
|
1997-01-01 00:29:52 +08:00
|
|
|
return -1;
|
1997-01-04 03:08:16 +08:00
|
|
|
*p = x;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
return get_long(v, (long *)p);
|
1997-01-01 00:29:52 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2001-06-11 07:40:19 +08:00
|
|
|
#ifdef HAVE_LONG_LONG
|
|
|
|
|
|
|
|
/* Same, but handling native long long. */
|
|
|
|
|
|
|
|
static int
|
|
|
|
get_longlong(PyObject *v, LONG_LONG *p)
|
|
|
|
{
|
|
|
|
LONG_LONG x;
|
|
|
|
|
2001-06-12 09:22:22 +08:00
|
|
|
v = get_pylong(v);
|
|
|
|
if (v == NULL)
|
|
|
|
return -1;
|
2001-06-11 07:40:19 +08:00
|
|
|
assert(PyLong_Check(v));
|
|
|
|
x = PyLong_AsLongLong(v);
|
2001-06-12 09:22:22 +08:00
|
|
|
Py_DECREF(v);
|
2001-06-11 07:40:19 +08:00
|
|
|
if (x == (LONG_LONG)-1 && PyErr_Occurred())
|
|
|
|
return -1;
|
|
|
|
*p = x;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Same, but handling native unsigned long long. */
|
|
|
|
|
|
|
|
static int
|
|
|
|
get_ulonglong(PyObject *v, unsigned LONG_LONG *p)
|
|
|
|
{
|
|
|
|
unsigned LONG_LONG x;
|
|
|
|
|
2001-06-12 09:22:22 +08:00
|
|
|
v = get_pylong(v);
|
|
|
|
if (v == NULL)
|
|
|
|
return -1;
|
2001-06-11 07:40:19 +08:00
|
|
|
assert(PyLong_Check(v));
|
|
|
|
x = PyLong_AsUnsignedLongLong(v);
|
2001-06-12 09:22:22 +08:00
|
|
|
Py_DECREF(v);
|
2001-06-11 07:40:19 +08:00
|
|
|
if (x == (unsigned LONG_LONG)-1 && PyErr_Occurred())
|
|
|
|
return -1;
|
|
|
|
*p = x;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|
1997-01-01 00:29:52 +08:00
|
|
|
|
1997-01-03 06:21:36 +08: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-03 07:23:20 +08:00
|
|
|
/* XXX Inf/NaN are not handled quite right (but underflow is!) */
|
1997-01-03 06:21:36 +08:00
|
|
|
|
|
|
|
static int
|
2000-07-10 20:29:26 +08:00
|
|
|
pack_float(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 */
|
1997-01-03 06:21:36 +08:00
|
|
|
{
|
|
|
|
int s;
|
|
|
|
int e;
|
1997-01-03 07:23:20 +08:00
|
|
|
double f;
|
|
|
|
long fbits;
|
1997-01-03 06:21:36 +08:00
|
|
|
|
|
|
|
if (x < 0) {
|
|
|
|
s = 1;
|
|
|
|
x = -x;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
s = 0;
|
1997-01-03 07:23:20 +08: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-03 06:21:36 +08:00
|
|
|
e--;
|
|
|
|
}
|
1997-01-03 07:23:20 +08:00
|
|
|
else if (f == 0.0) {
|
1997-01-03 06:21:36 +08:00
|
|
|
e = 0;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
PyErr_SetString(PyExc_SystemError,
|
|
|
|
"frexp() result out of range");
|
|
|
|
return -1;
|
|
|
|
}
|
1997-01-03 07:23:20 +08:00
|
|
|
|
|
|
|
if (e >= 128) {
|
|
|
|
/* XXX 128 itself is reserved for Inf/NaN */
|
1997-01-03 06:21:36 +08:00
|
|
|
PyErr_SetString(PyExc_OverflowError,
|
|
|
|
"float too large to pack with f format");
|
|
|
|
return -1;
|
|
|
|
}
|
1997-01-03 07:23:20 +08:00
|
|
|
else if (e < -126) {
|
|
|
|
/* Gradual underflow */
|
|
|
|
f = ldexp(f, 126 + e);
|
1997-01-03 06:21:36 +08:00
|
|
|
e = 0;
|
|
|
|
}
|
1997-11-05 01:12:33 +08:00
|
|
|
else if (!(e == 0 && f == 0.0)) {
|
1997-01-03 07:23:20 +08:00
|
|
|
e += 127;
|
|
|
|
f -= 1.0; /* Get rid of leading 1 */
|
1997-01-03 06:21:36 +08:00
|
|
|
}
|
|
|
|
|
1997-01-03 07:23:20 +08:00
|
|
|
f *= 8388608.0; /* 2**23 */
|
|
|
|
fbits = (long) floor(f + 0.5); /* Round */
|
|
|
|
|
1997-01-03 06:21:36 +08:00
|
|
|
/* First byte */
|
|
|
|
*p = (s<<7) | (e>>1);
|
|
|
|
p += incr;
|
|
|
|
|
|
|
|
/* Second byte */
|
1997-04-12 04:44:04 +08:00
|
|
|
*p = (char) (((e&1)<<7) | (fbits>>16));
|
1997-01-03 06:21:36 +08:00
|
|
|
p += incr;
|
|
|
|
|
|
|
|
/* Third byte */
|
1997-01-03 07:23:20 +08:00
|
|
|
*p = (fbits>>8) & 0xFF;
|
1997-01-03 06:21:36 +08:00
|
|
|
p += incr;
|
|
|
|
|
|
|
|
/* Fourth byte */
|
1997-01-03 07:23:20 +08:00
|
|
|
*p = fbits&0xFF;
|
1997-01-03 06:21:36 +08:00
|
|
|
|
|
|
|
/* Done */
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2000-07-10 20:29:26 +08:00
|
|
|
pack_double(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 */
|
1997-01-03 06:21:36 +08:00
|
|
|
{
|
|
|
|
int s;
|
|
|
|
int e;
|
1997-01-03 07:23:20 +08:00
|
|
|
double f;
|
1997-01-03 06:21:36 +08:00
|
|
|
long fhi, flo;
|
|
|
|
|
|
|
|
if (x < 0) {
|
|
|
|
s = 1;
|
|
|
|
x = -x;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
s = 0;
|
1997-01-03 07:23:20 +08: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-03 06:21:36 +08:00
|
|
|
e--;
|
|
|
|
}
|
1997-01-03 07:23:20 +08:00
|
|
|
else if (f == 0.0) {
|
1997-01-03 06:21:36 +08:00
|
|
|
e = 0;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
PyErr_SetString(PyExc_SystemError,
|
|
|
|
"frexp() result out of range");
|
|
|
|
return -1;
|
|
|
|
}
|
1997-01-03 07:23:20 +08:00
|
|
|
|
|
|
|
if (e >= 1024) {
|
|
|
|
/* XXX 1024 itself is reserved for Inf/NaN */
|
1997-01-03 06:21:36 +08:00
|
|
|
PyErr_SetString(PyExc_OverflowError,
|
|
|
|
"float too large to pack with d format");
|
|
|
|
return -1;
|
|
|
|
}
|
1997-01-03 07:23:20 +08:00
|
|
|
else if (e < -1022) {
|
|
|
|
/* Gradual underflow */
|
|
|
|
f = ldexp(f, 1022 + e);
|
1997-01-03 06:21:36 +08:00
|
|
|
e = 0;
|
|
|
|
}
|
1997-11-05 01:12:33 +08:00
|
|
|
else if (!(e == 0 && f == 0.0)) {
|
1997-01-03 07:23:20 +08:00
|
|
|
e += 1023;
|
|
|
|
f -= 1.0; /* Get rid of leading 1 */
|
1997-01-03 06:21:36 +08:00
|
|
|
}
|
|
|
|
|
1997-01-03 07:23:20 +08: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-03 06:21:36 +08:00
|
|
|
/* First byte */
|
|
|
|
*p = (s<<7) | (e>>4);
|
|
|
|
p += incr;
|
|
|
|
|
|
|
|
/* Second byte */
|
1997-04-12 04:44:04 +08:00
|
|
|
*p = (char) (((e&0xF)<<4) | (fhi>>24));
|
1997-01-03 06:21:36 +08: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 *
|
2000-07-10 20:29:26 +08:00
|
|
|
unpack_float(const char *p, /* Where the high order byte is */
|
|
|
|
int incr) /* 1 for big-endian; -1 for little-endian */
|
1997-01-03 06:21:36 +08:00
|
|
|
{
|
|
|
|
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-03 06:31:07 +08:00
|
|
|
if (e == 0)
|
|
|
|
e = -126;
|
|
|
|
else {
|
|
|
|
x += 1.0;
|
|
|
|
e -= 127;
|
|
|
|
}
|
|
|
|
x = ldexp(x, e);
|
1997-01-03 06:21:36 +08:00
|
|
|
|
|
|
|
if (s)
|
|
|
|
x = -x;
|
|
|
|
|
|
|
|
return PyFloat_FromDouble(x);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
2000-07-10 20:29:26 +08:00
|
|
|
unpack_double(const char *p, /* Where the high order byte is */
|
|
|
|
int incr) /* 1 for big-endian; -1 for little-endian */
|
1997-01-03 06:21:36 +08:00
|
|
|
{
|
|
|
|
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-03 06:31:07 +08:00
|
|
|
if (e == 0)
|
|
|
|
e = -1022;
|
|
|
|
else {
|
|
|
|
x += 1.0;
|
|
|
|
e -= 1023;
|
|
|
|
}
|
|
|
|
x = ldexp(x, e);
|
1997-01-03 06:21:36 +08: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 09:41:25 +08:00
|
|
|
/* The translation function for each format character is table driven */
|
|
|
|
|
|
|
|
typedef struct _formatdef {
|
|
|
|
char format;
|
1992-08-17 16:55:12 +08: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 09:41:25 +08:00
|
|
|
int alignment;
|
2000-07-09 11:09:57 +08:00
|
|
|
PyObject* (*unpack)(const char *,
|
|
|
|
const struct _formatdef *);
|
|
|
|
int (*pack)(char *, PyObject *,
|
|
|
|
const struct _formatdef *);
|
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 09:41:25 +08:00
|
|
|
} formatdef;
|
|
|
|
|
2001-06-11 07:40:19 +08:00
|
|
|
/* A large number of small routines follow, with names of the form
|
|
|
|
|
|
|
|
[bln][up]_TYPE
|
|
|
|
|
|
|
|
[bln] distiguishes among big-endian, little-endian and native.
|
|
|
|
[pu] distiguishes between pack (to struct) and unpack (from struct).
|
|
|
|
TYPE is one of char, byte, ubyte, etc.
|
|
|
|
*/
|
|
|
|
|
2001-06-12 09:22:22 +08:00
|
|
|
/* Native mode routines. ****************************************************/
|
2001-06-11 07:40:19 +08: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 09:41:25 +08:00
|
|
|
static PyObject *
|
2000-07-10 20:29:26 +08:00
|
|
|
nu_char(const char *p, const formatdef *f)
|
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 09:41:25 +08:00
|
|
|
{
|
|
|
|
return PyString_FromStringAndSize(p, 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
2000-07-10 20:29:26 +08:00
|
|
|
nu_byte(const char *p, const formatdef *f)
|
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 09:41:25 +08:00
|
|
|
{
|
|
|
|
return PyInt_FromLong((long) *(signed char *)p);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
2000-07-10 20:29:26 +08:00
|
|
|
nu_ubyte(const char *p, const formatdef *f)
|
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 09:41:25 +08:00
|
|
|
{
|
|
|
|
return PyInt_FromLong((long) *(unsigned char *)p);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
2000-07-10 20:29:26 +08:00
|
|
|
nu_short(const char *p, const formatdef *f)
|
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 09:41:25 +08:00
|
|
|
{
|
|
|
|
return PyInt_FromLong((long) *(short *)p);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
2000-07-10 20:29:26 +08:00
|
|
|
nu_ushort(const char *p, const formatdef *f)
|
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 09:41:25 +08:00
|
|
|
{
|
|
|
|
return PyInt_FromLong((long) *(unsigned short *)p);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
2000-07-10 20:29:26 +08:00
|
|
|
nu_int(const char *p, const formatdef *f)
|
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 09:41:25 +08:00
|
|
|
{
|
|
|
|
return PyInt_FromLong((long) *(int *)p);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
2000-07-10 20:29:26 +08:00
|
|
|
nu_uint(const char *p, const formatdef *f)
|
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 09:41:25 +08:00
|
|
|
{
|
|
|
|
unsigned int x = *(unsigned int *)p;
|
1997-01-04 03:08:16 +08: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 09:41:25 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
2000-07-10 20:29:26 +08:00
|
|
|
nu_long(const char *p, const formatdef *f)
|
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 09:41:25 +08:00
|
|
|
{
|
|
|
|
return PyInt_FromLong(*(long *)p);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
2000-07-10 20:29:26 +08:00
|
|
|
nu_ulong(const char *p, const formatdef *f)
|
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 09:41:25 +08:00
|
|
|
{
|
1997-01-04 03:08:16 +08: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 09:41:25 +08:00
|
|
|
}
|
|
|
|
|
2001-06-11 07:40:19 +08:00
|
|
|
/* Native mode doesn't support q or Q unless the platform C supports
|
|
|
|
long long (or, on Windows, __int64). */
|
|
|
|
|
|
|
|
#ifdef HAVE_LONG_LONG
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
nu_longlong(const char *p, const formatdef *f)
|
|
|
|
{
|
|
|
|
return PyLong_FromLongLong(*(LONG_LONG *)p);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
nu_ulonglong(const char *p, const formatdef *f)
|
|
|
|
{
|
|
|
|
return PyLong_FromUnsignedLongLong(*(unsigned LONG_LONG *)p);
|
|
|
|
}
|
|
|
|
#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 09:41:25 +08:00
|
|
|
static PyObject *
|
2000-07-10 20:29:26 +08:00
|
|
|
nu_float(const char *p, const formatdef *f)
|
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 09:41:25 +08:00
|
|
|
{
|
|
|
|
float x;
|
|
|
|
memcpy((char *)&x, p, sizeof(float));
|
|
|
|
return PyFloat_FromDouble((double)x);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
2000-07-10 20:29:26 +08:00
|
|
|
nu_double(const char *p, const formatdef *f)
|
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 09:41:25 +08:00
|
|
|
{
|
|
|
|
double x;
|
|
|
|
memcpy((char *)&x, p, sizeof(double));
|
|
|
|
return PyFloat_FromDouble(x);
|
|
|
|
}
|
|
|
|
|
1998-09-18 22:14:13 +08:00
|
|
|
static PyObject *
|
2000-07-10 20:29:26 +08:00
|
|
|
nu_void_p(const char *p, const formatdef *f)
|
1998-09-18 22:14:13 +08:00
|
|
|
{
|
|
|
|
return PyLong_FromVoidPtr(*(void **)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 09:41:25 +08:00
|
|
|
static int
|
2000-07-10 20:29:26 +08:00
|
|
|
np_byte(char *p, PyObject *v, const formatdef *f)
|
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 09:41:25 +08:00
|
|
|
{
|
|
|
|
long x;
|
|
|
|
if (get_long(v, &x) < 0)
|
|
|
|
return -1;
|
2000-09-15 15:31:57 +08:00
|
|
|
if (x < -128 || x > 127){
|
|
|
|
PyErr_SetString(StructError,
|
|
|
|
"byte format requires -128<=number<=127");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
*p = (char)x;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
np_ubyte(char *p, PyObject *v, const formatdef *f)
|
|
|
|
{
|
|
|
|
long x;
|
|
|
|
if (get_long(v, &x) < 0)
|
|
|
|
return -1;
|
|
|
|
if (x < 0 || x > 255){
|
|
|
|
PyErr_SetString(StructError,
|
|
|
|
"ubyte format requires 0<=number<=255");
|
|
|
|
return -1;
|
|
|
|
}
|
1997-04-12 04:44:04 +08: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 09:41:25 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2000-07-10 20:29:26 +08:00
|
|
|
np_char(char *p, PyObject *v, const formatdef *f)
|
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 09:41:25 +08:00
|
|
|
{
|
|
|
|
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
|
2000-07-10 20:29:26 +08:00
|
|
|
np_short(char *p, PyObject *v, const formatdef *f)
|
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 09:41:25 +08:00
|
|
|
{
|
|
|
|
long x;
|
|
|
|
if (get_long(v, &x) < 0)
|
|
|
|
return -1;
|
2000-09-15 16:10:33 +08:00
|
|
|
if (x < SHRT_MIN || x > SHRT_MAX){
|
2000-09-15 15:31:57 +08:00
|
|
|
PyErr_SetString(StructError,
|
2000-09-15 16:10:33 +08:00
|
|
|
"short format requires " STRINGIFY(SHRT_MIN)
|
|
|
|
"<=number<=" STRINGIFY(SHRT_MAX));
|
2000-09-15 15:31:57 +08:00
|
|
|
return -1;
|
|
|
|
}
|
1997-04-12 04:44:04 +08: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 09:41:25 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2000-09-15 15:31:57 +08:00
|
|
|
static int
|
|
|
|
np_ushort(char *p, PyObject *v, const formatdef *f)
|
|
|
|
{
|
|
|
|
long x;
|
|
|
|
if (get_long(v, &x) < 0)
|
|
|
|
return -1;
|
2000-09-15 16:10:33 +08:00
|
|
|
if (x < 0 || x > USHRT_MAX){
|
2000-09-15 15:31:57 +08:00
|
|
|
PyErr_SetString(StructError,
|
2000-09-15 16:10:33 +08:00
|
|
|
"short format requires 0<=number<=" STRINGIFY(USHRT_MAX));
|
2000-09-15 15:31:57 +08:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
* (unsigned short *)p = (unsigned short)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 09:41:25 +08:00
|
|
|
static int
|
2000-07-10 20:29:26 +08:00
|
|
|
np_int(char *p, PyObject *v, const formatdef *f)
|
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 09:41:25 +08:00
|
|
|
{
|
|
|
|
long x;
|
|
|
|
if (get_long(v, &x) < 0)
|
|
|
|
return -1;
|
|
|
|
* (int *)p = x;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
1997-01-01 00:29:52 +08:00
|
|
|
static int
|
2000-07-10 20:29:26 +08:00
|
|
|
np_uint(char *p, PyObject *v, const formatdef *f)
|
1997-01-01 00:29:52 +08:00
|
|
|
{
|
|
|
|
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 09:41:25 +08:00
|
|
|
static int
|
2000-07-10 20:29:26 +08:00
|
|
|
np_long(char *p, PyObject *v, const formatdef *f)
|
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 09:41:25 +08:00
|
|
|
{
|
|
|
|
long x;
|
|
|
|
if (get_long(v, &x) < 0)
|
|
|
|
return -1;
|
|
|
|
* (long *)p = x;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
1997-01-01 00:29:52 +08:00
|
|
|
static int
|
2000-07-10 20:29:26 +08:00
|
|
|
np_ulong(char *p, PyObject *v, const formatdef *f)
|
1997-01-01 00:29:52 +08:00
|
|
|
{
|
|
|
|
unsigned long x;
|
|
|
|
if (get_ulong(v, &x) < 0)
|
|
|
|
return -1;
|
|
|
|
* (unsigned long *)p = x;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2001-06-11 07:40:19 +08:00
|
|
|
#ifdef HAVE_LONG_LONG
|
|
|
|
|
|
|
|
static int
|
|
|
|
np_longlong(char *p, PyObject *v, const formatdef *f)
|
|
|
|
{
|
|
|
|
LONG_LONG x;
|
|
|
|
if (get_longlong(v, &x) < 0)
|
|
|
|
return -1;
|
|
|
|
* (LONG_LONG *)p = x;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
np_ulonglong(char *p, PyObject *v, const formatdef *f)
|
|
|
|
{
|
|
|
|
unsigned LONG_LONG x;
|
|
|
|
if (get_ulonglong(v, &x) < 0)
|
|
|
|
return -1;
|
|
|
|
* (unsigned LONG_LONG *)p = x;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#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 09:41:25 +08:00
|
|
|
static int
|
2000-07-10 20:29:26 +08:00
|
|
|
np_float(char *p, PyObject *v, const formatdef *f)
|
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 09:41:25 +08:00
|
|
|
{
|
|
|
|
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
|
2000-07-10 20:29:26 +08:00
|
|
|
np_double(char *p, PyObject *v, const formatdef *f)
|
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 09:41:25 +08:00
|
|
|
{
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
1998-09-18 22:14:13 +08:00
|
|
|
static int
|
2000-07-10 20:29:26 +08:00
|
|
|
np_void_p(char *p, PyObject *v, const formatdef *f)
|
1998-09-18 22:14:13 +08:00
|
|
|
{
|
|
|
|
void *x = PyLong_AsVoidPtr(v);
|
|
|
|
if (x == NULL && PyErr_Occurred()) {
|
|
|
|
/* ### hrm. PyLong_AsVoidPtr raises SystemError */
|
|
|
|
if (PyErr_ExceptionMatches(PyExc_TypeError))
|
|
|
|
PyErr_SetString(StructError,
|
|
|
|
"required argument is not an integer");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
*(void **)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 09:41:25 +08:00
|
|
|
static formatdef native_table[] = {
|
|
|
|
{'x', sizeof(char), 0, NULL},
|
|
|
|
{'b', sizeof(char), 0, nu_byte, np_byte},
|
2000-09-15 15:31:57 +08:00
|
|
|
{'B', sizeof(char), 0, nu_ubyte, np_ubyte},
|
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 09:41:25 +08:00
|
|
|
{'c', sizeof(char), 0, nu_char, np_char},
|
|
|
|
{'s', sizeof(char), 0, NULL},
|
1997-09-05 15:08:39 +08:00
|
|
|
{'p', sizeof(char), 0, 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 09:41:25 +08:00
|
|
|
{'h', sizeof(short), SHORT_ALIGN, nu_short, np_short},
|
2000-09-15 15:31:57 +08:00
|
|
|
{'H', sizeof(short), SHORT_ALIGN, nu_ushort, np_ushort},
|
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 09:41:25 +08:00
|
|
|
{'i', sizeof(int), INT_ALIGN, nu_int, np_int},
|
1997-01-01 00:29:52 +08: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 09:41:25 +08:00
|
|
|
{'l', sizeof(long), LONG_ALIGN, nu_long, np_long},
|
1997-01-01 00:29:52 +08: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 09:41:25 +08:00
|
|
|
{'f', sizeof(float), FLOAT_ALIGN, nu_float, np_float},
|
|
|
|
{'d', sizeof(double), DOUBLE_ALIGN, nu_double, np_double},
|
1998-09-18 22:14:13 +08:00
|
|
|
{'P', sizeof(void *), VOID_P_ALIGN, nu_void_p, np_void_p},
|
2001-06-11 07:40:19 +08:00
|
|
|
#ifdef HAVE_LONG_LONG
|
|
|
|
{'q', sizeof(LONG_LONG), LONG_LONG_ALIGN, nu_longlong, np_longlong},
|
|
|
|
{'Q', sizeof(LONG_LONG), LONG_LONG_ALIGN, nu_ulonglong,np_ulonglong},
|
|
|
|
#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 09:41:25 +08:00
|
|
|
{0}
|
|
|
|
};
|
|
|
|
|
2001-06-12 09:22:22 +08:00
|
|
|
/* Big-endian routines. *****************************************************/
|
|
|
|
|
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 09:41:25 +08:00
|
|
|
static PyObject *
|
2000-07-10 20:29:26 +08:00
|
|
|
bu_int(const char *p, const formatdef *f)
|
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 09:41:25 +08:00
|
|
|
{
|
|
|
|
long x = 0;
|
|
|
|
int i = f->size;
|
|
|
|
do {
|
|
|
|
x = (x<<8) | (*p++ & 0xFF);
|
|
|
|
} while (--i > 0);
|
2001-04-09 07:39:38 +08:00
|
|
|
/* Extend the sign bit. */
|
|
|
|
if (SIZEOF_LONG > f->size)
|
|
|
|
x |= -(x & (1L << (8*f->size - 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 09:41:25 +08:00
|
|
|
return PyInt_FromLong(x);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
2000-07-10 20:29:26 +08:00
|
|
|
bu_uint(const char *p, const formatdef *f)
|
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 09:41:25 +08:00
|
|
|
{
|
1997-01-04 03:08:16 +08: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 09:41:25 +08:00
|
|
|
int i = f->size;
|
|
|
|
do {
|
|
|
|
x = (x<<8) | (*p++ & 0xFF);
|
|
|
|
} while (--i > 0);
|
1998-06-29 12:00:40 +08:00
|
|
|
if (f->size >= 4)
|
|
|
|
return PyLong_FromUnsignedLong(x);
|
|
|
|
else
|
|
|
|
return PyInt_FromLong((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 09:41:25 +08:00
|
|
|
}
|
|
|
|
|
2001-06-12 09:22:22 +08:00
|
|
|
static PyObject *
|
|
|
|
bu_longlong(const char *p, const formatdef *f)
|
|
|
|
{
|
|
|
|
return _PyLong_FromByteArray((const unsigned char *)p,
|
|
|
|
8,
|
|
|
|
0, /* little-endian */
|
|
|
|
1 /* signed */);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
bu_ulonglong(const char *p, const formatdef *f)
|
|
|
|
{
|
|
|
|
return _PyLong_FromByteArray((const unsigned char *)p,
|
|
|
|
8,
|
|
|
|
0, /* little-endian */
|
|
|
|
0 /* signed */);
|
|
|
|
}
|
|
|
|
|
1997-01-03 06:21:36 +08:00
|
|
|
static PyObject *
|
2000-07-10 20:29:26 +08:00
|
|
|
bu_float(const char *p, const formatdef *f)
|
1997-01-03 06:21:36 +08:00
|
|
|
{
|
|
|
|
return unpack_float(p, 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
2000-07-10 20:29:26 +08:00
|
|
|
bu_double(const char *p, const formatdef *f)
|
1997-01-03 06:21:36 +08:00
|
|
|
{
|
|
|
|
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 09:41:25 +08:00
|
|
|
static int
|
2000-07-10 20:29:26 +08:00
|
|
|
bp_int(char *p, PyObject *v, const formatdef *f)
|
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 09:41:25 +08:00
|
|
|
{
|
|
|
|
long x;
|
|
|
|
int i;
|
|
|
|
if (get_long(v, &x) < 0)
|
|
|
|
return -1;
|
|
|
|
i = f->size;
|
|
|
|
do {
|
1997-04-12 04:44:04 +08: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 09:41:25 +08:00
|
|
|
x >>= 8;
|
|
|
|
} while (i > 0);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
1997-01-01 00:29:52 +08:00
|
|
|
static int
|
2000-07-10 20:29:26 +08:00
|
|
|
bp_uint(char *p, PyObject *v, const formatdef *f)
|
1997-01-01 00:29:52 +08:00
|
|
|
{
|
|
|
|
unsigned long x;
|
|
|
|
int i;
|
|
|
|
if (get_ulong(v, &x) < 0)
|
|
|
|
return -1;
|
|
|
|
i = f->size;
|
|
|
|
do {
|
1997-04-12 04:44:04 +08:00
|
|
|
p[--i] = (char)x;
|
1997-01-01 00:29:52 +08:00
|
|
|
x >>= 8;
|
|
|
|
} while (i > 0);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2001-06-12 09:22:22 +08:00
|
|
|
static int
|
|
|
|
bp_longlong(char *p, PyObject *v, const formatdef *f)
|
|
|
|
{
|
|
|
|
int res;
|
|
|
|
v = get_pylong(v);
|
2001-06-13 09:26:35 +08:00
|
|
|
if (v == NULL)
|
|
|
|
return -1;
|
2001-06-12 09:22:22 +08:00
|
|
|
res = _PyLong_AsByteArray((PyLongObject *)v,
|
|
|
|
(unsigned char *)p,
|
|
|
|
8,
|
|
|
|
0, /* little_endian */
|
|
|
|
1 /* signed */);
|
|
|
|
Py_DECREF(v);
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
bp_ulonglong(char *p, PyObject *v, const formatdef *f)
|
|
|
|
{
|
|
|
|
int res;
|
|
|
|
v = get_pylong(v);
|
2001-06-13 09:26:35 +08:00
|
|
|
if (v == NULL)
|
|
|
|
return -1;
|
2001-06-12 09:22:22 +08:00
|
|
|
res = _PyLong_AsByteArray((PyLongObject *)v,
|
|
|
|
(unsigned char *)p,
|
|
|
|
8,
|
|
|
|
0, /* little_endian */
|
|
|
|
0 /* signed */);
|
|
|
|
Py_DECREF(v);
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
1997-01-03 06:21:36 +08:00
|
|
|
static int
|
2000-07-10 20:29:26 +08:00
|
|
|
bp_float(char *p, PyObject *v, const formatdef *f)
|
1997-01-03 06:21:36 +08:00
|
|
|
{
|
|
|
|
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
|
2000-07-10 20:29:26 +08:00
|
|
|
bp_double(char *p, PyObject *v, const formatdef *f)
|
1997-01-03 06:21:36 +08:00
|
|
|
{
|
|
|
|
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 09:41:25 +08: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},
|
1997-09-05 15:08:39 +08:00
|
|
|
{'p', 1, 0, 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 09:41:25 +08:00
|
|
|
{'h', 2, 0, bu_int, bp_int},
|
1997-01-01 00:29:52 +08: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 09:41:25 +08:00
|
|
|
{'i', 4, 0, bu_int, bp_int},
|
1997-01-01 00:29:52 +08: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 09:41:25 +08:00
|
|
|
{'l', 4, 0, bu_int, bp_int},
|
1997-01-01 00:29:52 +08:00
|
|
|
{'L', 4, 0, bu_uint, bp_uint},
|
2001-06-12 09:22:22 +08:00
|
|
|
{'q', 8, 0, bu_longlong, bp_longlong},
|
|
|
|
{'Q', 8, 0, bu_ulonglong, bp_ulonglong},
|
1997-01-03 06:21:36 +08: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 09:41:25 +08:00
|
|
|
{0}
|
|
|
|
};
|
|
|
|
|
2001-06-12 09:22:22 +08:00
|
|
|
/* Little-endian routines. *****************************************************/
|
|
|
|
|
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 09:41:25 +08:00
|
|
|
static PyObject *
|
2000-07-10 20:29:26 +08:00
|
|
|
lu_int(const char *p, const formatdef *f)
|
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 09:41:25 +08:00
|
|
|
{
|
|
|
|
long x = 0;
|
|
|
|
int i = f->size;
|
|
|
|
do {
|
|
|
|
x = (x<<8) | (p[--i] & 0xFF);
|
|
|
|
} while (i > 0);
|
2001-04-09 07:39:38 +08:00
|
|
|
/* Extend the sign bit. */
|
|
|
|
if (SIZEOF_LONG > f->size)
|
|
|
|
x |= -(x & (1L << (8*f->size - 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 09:41:25 +08:00
|
|
|
return PyInt_FromLong(x);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
2000-07-10 20:29:26 +08:00
|
|
|
lu_uint(const char *p, const formatdef *f)
|
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 09:41:25 +08:00
|
|
|
{
|
1997-01-04 03:08:16 +08: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 09:41:25 +08:00
|
|
|
int i = f->size;
|
|
|
|
do {
|
|
|
|
x = (x<<8) | (p[--i] & 0xFF);
|
|
|
|
} while (i > 0);
|
1998-06-29 12:00:40 +08:00
|
|
|
if (f->size >= 4)
|
|
|
|
return PyLong_FromUnsignedLong(x);
|
|
|
|
else
|
|
|
|
return PyInt_FromLong((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 09:41:25 +08:00
|
|
|
}
|
|
|
|
|
2001-06-12 09:22:22 +08:00
|
|
|
static PyObject *
|
|
|
|
lu_longlong(const char *p, const formatdef *f)
|
|
|
|
{
|
|
|
|
return _PyLong_FromByteArray((const unsigned char *)p,
|
|
|
|
8,
|
|
|
|
1, /* little-endian */
|
|
|
|
1 /* signed */);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
|
|
|
lu_ulonglong(const char *p, const formatdef *f)
|
|
|
|
{
|
|
|
|
return _PyLong_FromByteArray((const unsigned char *)p,
|
|
|
|
8,
|
|
|
|
1, /* little-endian */
|
|
|
|
0 /* signed */);
|
|
|
|
}
|
|
|
|
|
1997-01-03 06:21:36 +08:00
|
|
|
static PyObject *
|
2000-07-10 20:29:26 +08:00
|
|
|
lu_float(const char *p, const formatdef *f)
|
1997-01-03 06:21:36 +08:00
|
|
|
{
|
|
|
|
return unpack_float(p+3, -1);
|
|
|
|
}
|
|
|
|
|
|
|
|
static PyObject *
|
2000-07-10 20:29:26 +08:00
|
|
|
lu_double(const char *p, const formatdef *f)
|
1997-01-03 06:21:36 +08:00
|
|
|
{
|
|
|
|
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 09:41:25 +08:00
|
|
|
static int
|
2000-07-10 20:29:26 +08:00
|
|
|
lp_int(char *p, PyObject *v, const formatdef *f)
|
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 09:41:25 +08:00
|
|
|
{
|
|
|
|
long x;
|
|
|
|
int i;
|
|
|
|
if (get_long(v, &x) < 0)
|
|
|
|
return -1;
|
|
|
|
i = f->size;
|
|
|
|
do {
|
1997-04-12 04:44:04 +08: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 09:41:25 +08:00
|
|
|
x >>= 8;
|
|
|
|
} while (--i > 0);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
1997-01-01 00:29:52 +08:00
|
|
|
static int
|
2000-07-10 20:29:26 +08:00
|
|
|
lp_uint(char *p, PyObject *v, const formatdef *f)
|
1997-01-01 00:29:52 +08:00
|
|
|
{
|
|
|
|
unsigned long x;
|
|
|
|
int i;
|
|
|
|
if (get_ulong(v, &x) < 0)
|
|
|
|
return -1;
|
|
|
|
i = f->size;
|
|
|
|
do {
|
1997-04-12 04:44:04 +08:00
|
|
|
*p++ = (char)x;
|
1997-01-01 00:29:52 +08:00
|
|
|
x >>= 8;
|
|
|
|
} while (--i > 0);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2001-06-12 09:22:22 +08:00
|
|
|
static int
|
|
|
|
lp_longlong(char *p, PyObject *v, const formatdef *f)
|
|
|
|
{
|
|
|
|
int res;
|
|
|
|
v = get_pylong(v);
|
2001-06-13 09:26:35 +08:00
|
|
|
if (v == NULL)
|
|
|
|
return -1;
|
2001-06-12 09:22:22 +08:00
|
|
|
res = _PyLong_AsByteArray((PyLongObject*)v,
|
|
|
|
(unsigned char *)p,
|
|
|
|
8,
|
|
|
|
1, /* little_endian */
|
|
|
|
1 /* signed */);
|
|
|
|
Py_DECREF(v);
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
lp_ulonglong(char *p, PyObject *v, const formatdef *f)
|
|
|
|
{
|
|
|
|
int res;
|
|
|
|
v = get_pylong(v);
|
2001-06-13 09:26:35 +08:00
|
|
|
if (v == NULL)
|
|
|
|
return -1;
|
2001-06-12 09:22:22 +08:00
|
|
|
res = _PyLong_AsByteArray((PyLongObject*)v,
|
|
|
|
(unsigned char *)p,
|
|
|
|
8,
|
|
|
|
1, /* little_endian */
|
|
|
|
0 /* signed */);
|
|
|
|
Py_DECREF(v);
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
1997-01-03 06:21:36 +08:00
|
|
|
static int
|
2000-07-10 20:29:26 +08:00
|
|
|
lp_float(char *p, PyObject *v, const formatdef *f)
|
1997-01-03 06:21:36 +08:00
|
|
|
{
|
|
|
|
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
|
2000-07-10 20:29:26 +08:00
|
|
|
lp_double(char *p, PyObject *v, const formatdef *f)
|
1997-01-03 06:21:36 +08:00
|
|
|
{
|
|
|
|
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 09:41:25 +08: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},
|
1997-09-05 15:08:39 +08:00
|
|
|
{'p', 1, 0, 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 09:41:25 +08:00
|
|
|
{'h', 2, 0, lu_int, lp_int},
|
1997-01-01 00:29:52 +08: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 09:41:25 +08:00
|
|
|
{'i', 4, 0, lu_int, lp_int},
|
1997-01-01 00:29:52 +08: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 09:41:25 +08:00
|
|
|
{'l', 4, 0, lu_int, lp_int},
|
1997-01-01 00:29:52 +08:00
|
|
|
{'L', 4, 0, lu_uint, lp_uint},
|
2001-06-12 09:22:22 +08:00
|
|
|
{'q', 8, 0, lu_longlong, lp_longlong},
|
|
|
|
{'Q', 8, 0, lu_ulonglong, lp_ulonglong},
|
1997-01-03 06:21:36 +08: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 09:41:25 +08:00
|
|
|
{0}
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
static const formatdef *
|
2000-07-10 20:29:26 +08:00
|
|
|
whichtable(char **pfmt)
|
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 09:41:25 +08:00
|
|
|
{
|
|
|
|
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 *
|
2000-07-10 20:29:26 +08:00
|
|
|
getentry(int c, const formatdef *f)
|
1992-08-17 16:55:12 +08: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 09:41:25 +08: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 16:55:12 +08: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 09:41:25 +08:00
|
|
|
static int
|
2000-07-10 20:29:26 +08:00
|
|
|
align(int size, int c, const formatdef *e)
|
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 09:41:25 +08:00
|
|
|
{
|
|
|
|
if (e->format == c) {
|
|
|
|
if (e->alignment) {
|
|
|
|
size = ((size + e->alignment - 1)
|
|
|
|
/ e->alignment)
|
|
|
|
* e->alignment;
|
|
|
|
}
|
1992-08-17 16:55:12 +08: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 09:41:25 +08:00
|
|
|
return size;
|
1992-08-17 16:55:12 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* calculate the size of a format string */
|
|
|
|
|
|
|
|
static int
|
2000-07-10 20:29:26 +08:00
|
|
|
calcsize(const char *fmt, const formatdef *f)
|
1992-08-17 16:55:12 +08: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 09:41:25 +08:00
|
|
|
const formatdef *e;
|
|
|
|
const char *s;
|
1992-08-17 16:55:12 +08:00
|
|
|
char c;
|
|
|
|
int size, num, itemsize, x;
|
|
|
|
|
|
|
|
s = fmt;
|
|
|
|
size = 0;
|
|
|
|
while ((c = *s++) != '\0') {
|
1998-04-11 06:27:42 +08:00
|
|
|
if (isspace((int)c))
|
1997-08-27 04:39:54 +08:00
|
|
|
continue;
|
1992-08-17 16:55:12 +08:00
|
|
|
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 09:41:25 +08:00
|
|
|
PyErr_SetString(
|
|
|
|
StructError,
|
|
|
|
"overflow in item count");
|
1992-08-17 16:55:12 +08:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
num = x;
|
|
|
|
}
|
|
|
|
if (c == '\0')
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
num = 1;
|
2001-06-12 00:57:33 +08: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 09:41:25 +08:00
|
|
|
e = getentry(c, f);
|
|
|
|
if (e == NULL)
|
1992-08-17 16:55:12 +08: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 09:41:25 +08:00
|
|
|
itemsize = e->size;
|
|
|
|
size = align(size, c, e);
|
1992-08-17 16:55:12 +08:00
|
|
|
x = num * itemsize;
|
|
|
|
size += x;
|
|
|
|
if (x/itemsize != num || size < 0) {
|
1996-12-13 07:32:31 +08:00
|
|
|
PyErr_SetString(StructError,
|
|
|
|
"total struct size too long");
|
1992-08-17 16:55:12 +08:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return size;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-12-19 12:24:24 +08:00
|
|
|
static char calcsize__doc__[] = "\
|
|
|
|
calcsize(fmt) -> int\n\
|
|
|
|
Return size of C struct described by format string fmt.\n\
|
|
|
|
See struct.__doc__ for more on format strings.";
|
1992-08-17 16:55:12 +08:00
|
|
|
|
1996-12-13 07:32:31 +08:00
|
|
|
static PyObject *
|
2000-07-10 20:29:26 +08:00
|
|
|
struct_calcsize(PyObject *self, PyObject *args)
|
1992-08-17 16:55:12 +08: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 09:41:25 +08:00
|
|
|
const formatdef *f;
|
1992-08-17 16:55:12 +08:00
|
|
|
int size;
|
|
|
|
|
2000-02-29 21:59:29 +08:00
|
|
|
if (!PyArg_ParseTuple(args, "s:calcsize", &fmt))
|
1992-08-17 16:55:12 +08: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 09:41:25 +08:00
|
|
|
f = whichtable(&fmt);
|
|
|
|
size = calcsize(fmt, f);
|
1992-08-17 16:55:12 +08:00
|
|
|
if (size < 0)
|
|
|
|
return NULL;
|
1996-12-13 07:32:31 +08:00
|
|
|
return PyInt_FromLong((long)size);
|
1992-08-17 16:55:12 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-12-19 12:24:24 +08:00
|
|
|
static char pack__doc__[] = "\
|
|
|
|
pack(fmt, v1, v2, ...) -> string\n\
|
|
|
|
Return string containing values v1, v2, ... packed according to fmt.\n\
|
|
|
|
See struct.__doc__ for more on format strings.";
|
1992-08-17 16:55:12 +08:00
|
|
|
|
1996-12-13 07:32:31 +08:00
|
|
|
static PyObject *
|
2000-07-10 20:29:26 +08:00
|
|
|
struct_pack(PyObject *self, PyObject *args)
|
1992-08-17 16:55:12 +08: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 09:41:25 +08:00
|
|
|
const formatdef *f, *e;
|
1996-12-13 07:32:31 +08:00
|
|
|
PyObject *format, *result, *v;
|
1992-08-17 16:55:12 +08:00
|
|
|
char *fmt;
|
|
|
|
int size, num;
|
|
|
|
int i, n;
|
1997-01-03 23:40:33 +08:00
|
|
|
char *s, *res, *restart, *nres;
|
1992-08-17 16:55:12 +08:00
|
|
|
char c;
|
|
|
|
|
1996-12-13 07:32:31 +08:00
|
|
|
if (args == NULL || !PyTuple_Check(args) ||
|
|
|
|
(n = PyTuple_Size(args)) < 1)
|
|
|
|
{
|
2001-06-12 00:57:33 +08:00
|
|
|
PyErr_SetString(PyExc_TypeError,
|
2000-06-01 10:02:46 +08:00
|
|
|
"struct.pack requires at least one argument");
|
1992-08-17 16:55:12 +08:00
|
|
|
return NULL;
|
|
|
|
}
|
1996-12-13 07:32:31 +08:00
|
|
|
format = PyTuple_GetItem(args, 0);
|
|
|
|
if (!PyArg_Parse(format, "s", &fmt))
|
1992-08-17 16:55:12 +08: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 09:41:25 +08:00
|
|
|
f = whichtable(&fmt);
|
|
|
|
size = calcsize(fmt, f);
|
1992-08-17 16:55:12 +08:00
|
|
|
if (size < 0)
|
|
|
|
return NULL;
|
1996-12-13 07:32:31 +08:00
|
|
|
result = PyString_FromStringAndSize((char *)NULL, size);
|
1992-08-17 16:55:12 +08:00
|
|
|
if (result == NULL)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
s = fmt;
|
|
|
|
i = 1;
|
1996-12-13 07:32:31 +08:00
|
|
|
res = restart = PyString_AsString(result);
|
1992-08-17 16:55:12 +08:00
|
|
|
|
|
|
|
while ((c = *s++) != '\0') {
|
1998-04-11 06:27:42 +08:00
|
|
|
if (isspace((int)c))
|
1997-08-27 04:39:54 +08:00
|
|
|
continue;
|
1992-08-17 16:55:12 +08:00
|
|
|
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 09:41:25 +08:00
|
|
|
e = getentry(c, f);
|
|
|
|
if (e == NULL)
|
|
|
|
goto fail;
|
1997-01-03 23:40:33 +08:00
|
|
|
nres = restart + align((int)(res-restart), c, e);
|
|
|
|
/* Fill padd bytes with zeros */
|
|
|
|
while (res < nres)
|
|
|
|
*res++ = '\0';
|
1996-12-31 10:10:45 +08: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 09:41:25 +08:00
|
|
|
do {
|
|
|
|
if (c == 'x') {
|
|
|
|
/* doesn't consume arguments */
|
1996-12-31 10:10:45 +08: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 09:41:25 +08:00
|
|
|
res += num;
|
1992-08-17 16:55:12 +08: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 09:41:25 +08:00
|
|
|
}
|
|
|
|
if (i >= n) {
|
|
|
|
PyErr_SetString(StructError,
|
|
|
|
"insufficient arguments to pack");
|
|
|
|
goto fail;
|
1992-08-17 16:55:12 +08: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 09:41:25 +08: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-13 07:32:31 +08: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 09:41:25 +08:00
|
|
|
"argument for 's' must be a string");
|
1992-08-17 16:55:12 +08: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 09:41:25 +08: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 10:10:45 +08: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 09:41:25 +08:00
|
|
|
res += num;
|
1992-08-17 16:55:12 +08: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 09:41:25 +08:00
|
|
|
}
|
1997-09-05 15:08:39 +08:00
|
|
|
else if (c == 'p') {
|
|
|
|
/* num is string size + 1,
|
|
|
|
to fit in the count byte */
|
|
|
|
int n;
|
|
|
|
num--; /* now num is max string size */
|
|
|
|
if (!PyString_Check(v)) {
|
|
|
|
PyErr_SetString(StructError,
|
|
|
|
"argument for 'p' must be a string");
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
n = PyString_Size(v);
|
|
|
|
if (n > num)
|
|
|
|
n = num;
|
|
|
|
if (n > 0)
|
|
|
|
memcpy(res+1, PyString_AsString(v), n);
|
|
|
|
if (n < num)
|
|
|
|
/* no real need, just to be nice */
|
|
|
|
memset(res+1+n, '\0', num-n);
|
|
|
|
*res++ = n; /* store the length byte */
|
|
|
|
res += num;
|
|
|
|
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 09:41:25 +08:00
|
|
|
else {
|
|
|
|
if (e->pack(res, v, e) < 0)
|
1992-08-17 16:55:12 +08: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 09:41:25 +08:00
|
|
|
res += e->size;
|
1992-08-17 16:55:12 +08: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 09:41:25 +08:00
|
|
|
} while (--num > 0);
|
1992-08-17 16:55:12 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (i < n) {
|
1996-12-13 07:32:31 +08: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 09:41:25 +08:00
|
|
|
"too many arguments for pack format");
|
1992-08-17 16:55:12 +08:00
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
return result;
|
|
|
|
|
|
|
|
fail:
|
1996-12-13 07:32:31 +08:00
|
|
|
Py_DECREF(result);
|
1992-08-17 16:55:12 +08:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-12-21 14:46:20 +08:00
|
|
|
static char unpack__doc__[] = "\
|
|
|
|
unpack(fmt, string) -> (v1, v2, ...)\n\
|
|
|
|
Unpack the string, containing packed C structure data, according\n\
|
|
|
|
to fmt. Requires len(string)==calcsize(fmt).\n\
|
1997-12-19 12:24:24 +08:00
|
|
|
See struct.__doc__ for more on format strings.";
|
1992-08-17 16:55:12 +08:00
|
|
|
|
1996-12-13 07:32:31 +08:00
|
|
|
static PyObject *
|
2000-07-10 20:29:26 +08:00
|
|
|
struct_unpack(PyObject *self, PyObject *args)
|
1992-08-17 16:55:12 +08: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 09:41:25 +08:00
|
|
|
const formatdef *f, *e;
|
1992-08-17 16:55:12 +08:00
|
|
|
char *str, *start, *fmt, *s;
|
|
|
|
char c;
|
1997-01-03 08:26:28 +08:00
|
|
|
int len, size, num;
|
1996-12-13 07:32:31 +08:00
|
|
|
PyObject *res, *v;
|
1992-08-17 16:55:12 +08:00
|
|
|
|
2000-02-29 21:59:29 +08:00
|
|
|
if (!PyArg_ParseTuple(args, "ss#:unpack", &fmt, &start, &len))
|
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 09:41:25 +08:00
|
|
|
return NULL;
|
|
|
|
f = whichtable(&fmt);
|
|
|
|
size = calcsize(fmt, f);
|
|
|
|
if (size < 0)
|
1992-08-17 16:55:12 +08:00
|
|
|
return NULL;
|
|
|
|
if (size != len) {
|
1996-12-13 07:32:31 +08: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 09:41:25 +08:00
|
|
|
"unpack str size does not match format");
|
1992-08-17 16:55:12 +08:00
|
|
|
return NULL;
|
|
|
|
}
|
1996-12-13 07:32:31 +08:00
|
|
|
res = PyList_New(0);
|
1992-08-17 16:55:12 +08:00
|
|
|
if (res == NULL)
|
|
|
|
return NULL;
|
|
|
|
str = start;
|
|
|
|
s = fmt;
|
|
|
|
while ((c = *s++) != '\0') {
|
1998-04-11 06:27:42 +08:00
|
|
|
if (isspace((int)c))
|
1997-08-27 04:39:54 +08:00
|
|
|
continue;
|
1992-08-17 16:55:12 +08:00
|
|
|
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 09:41:25 +08:00
|
|
|
e = getentry(c, f);
|
|
|
|
if (e == NULL)
|
|
|
|
goto fail;
|
|
|
|
str = start + align((int)(str-start), c, e);
|
1996-12-31 10:10:45 +08:00
|
|
|
if (num == 0 && c != 's')
|
|
|
|
continue;
|
1992-08-17 16:55:12 +08: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 09:41:25 +08:00
|
|
|
do {
|
|
|
|
if (c == 'x') {
|
|
|
|
str += num;
|
1992-08-17 16:55:12 +08: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 09:41:25 +08:00
|
|
|
}
|
|
|
|
if (c == 's') {
|
|
|
|
/* num is string size, not repeat count */
|
|
|
|
v = PyString_FromStringAndSize(str, num);
|
|
|
|
if (v == NULL)
|
1997-09-05 15:08:39 +08:00
|
|
|
goto fail;
|
|
|
|
str += num;
|
|
|
|
num = 0;
|
|
|
|
}
|
|
|
|
else if (c == 'p') {
|
|
|
|
/* num is string buffer size,
|
|
|
|
not repeat count */
|
|
|
|
int n = *(unsigned char*)str;
|
|
|
|
/* first byte (unsigned) is string size */
|
|
|
|
if (n >= num)
|
|
|
|
n = num-1;
|
|
|
|
v = PyString_FromStringAndSize(str+1, n);
|
|
|
|
if (v == 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 09:41:25 +08:00
|
|
|
goto fail;
|
|
|
|
str += num;
|
|
|
|
num = 0;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
v = e->unpack(str, e);
|
|
|
|
if (v == NULL)
|
|
|
|
goto fail;
|
|
|
|
str += e->size;
|
1992-08-17 16:55:12 +08:00
|
|
|
}
|
1996-12-13 07:32:31 +08:00
|
|
|
if (v == NULL || PyList_Append(res, v) < 0)
|
1992-08-17 16:55:12 +08:00
|
|
|
goto fail;
|
1996-12-13 07:32:31 +08: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 09:41:25 +08:00
|
|
|
} while (--num > 0);
|
1992-08-17 16:55:12 +08: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 09:41:25 +08:00
|
|
|
v = PyList_AsTuple(res);
|
|
|
|
Py_DECREF(res);
|
|
|
|
return v;
|
1992-08-17 16:55:12 +08:00
|
|
|
|
|
|
|
fail:
|
1996-12-13 07:32:31 +08:00
|
|
|
Py_DECREF(res);
|
1992-08-17 16:55:12 +08:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
1992-08-20 00:44:15 +08:00
|
|
|
|
1992-08-17 16:55:12 +08:00
|
|
|
/* List of functions */
|
|
|
|
|
1996-12-13 07:32:31 +08:00
|
|
|
static PyMethodDef struct_methods[] = {
|
1997-12-19 12:24:24 +08:00
|
|
|
{"calcsize", struct_calcsize, METH_VARARGS, calcsize__doc__},
|
|
|
|
{"pack", struct_pack, METH_VARARGS, pack__doc__},
|
|
|
|
{"unpack", struct_unpack, METH_VARARGS, unpack__doc__},
|
1992-08-17 16:55:12 +08:00
|
|
|
{NULL, NULL} /* sentinel */
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
/* Module initialization */
|
|
|
|
|
1998-12-05 02:50:17 +08:00
|
|
|
DL_EXPORT(void)
|
2000-07-21 14:00:07 +08:00
|
|
|
initstruct(void)
|
1992-08-17 16:55:12 +08:00
|
|
|
{
|
1996-12-13 07:32:31 +08:00
|
|
|
PyObject *m, *d;
|
1992-08-17 16:55:12 +08:00
|
|
|
|
|
|
|
/* Create the module and add the functions */
|
1997-12-19 12:24:24 +08:00
|
|
|
m = Py_InitModule4("struct", struct_methods, struct__doc__,
|
|
|
|
(PyObject*)NULL, PYTHON_API_VERSION);
|
1992-08-17 16:55:12 +08:00
|
|
|
|
|
|
|
/* Add some symbolic constants to the module */
|
1996-12-13 07:32:31 +08:00
|
|
|
d = PyModule_GetDict(m);
|
1997-10-01 12:29:29 +08:00
|
|
|
StructError = PyErr_NewException("struct.error", NULL, NULL);
|
|
|
|
if (StructError == NULL)
|
|
|
|
return;
|
1996-12-13 07:32:31 +08:00
|
|
|
PyDict_SetItemString(d, "error", StructError);
|
1992-08-17 16:55:12 +08:00
|
|
|
}
|