#include <tuple.h>
Data Fields | |
int | tag |
union { | |
int i | |
double d | |
struct { | |
char * ptr | |
int len | |
} s | |
} | data |
Definition at line 114 of file tuple.h.
|
Double-precision floating-point value for a tuple element. Eight bytes on an Intel Linux box. |
|
Since I'm only concerned with Linux running on Intel hardware, it's safe to say this union is an eight-byte field. Referenced by LinuxTuple_to_PyTuple, main, make_tuple_internal, print_element, PyTuple_to_LinuxTuple, recv_tuple, send_tuple, tuple_double_field, tuple_int_field, tuple_string_field, and tuples_match. |
|
Integer value for a tuple element. Four bytes on an Intel Linux box. |
|
The length of a string. We do not depend on zero-termination bytes for strings, because we want to be able to use strings to move arbitrary binary data around. Strings can be large. |
|
A pointer to the memory space for a string. |
|
String value for a tuple element. Strings can be ASCII strings, or they can be a handy efficient way to move around binary data, such as arrays of doubles or structs. |
|
Data type for this element. The values are `i' for integer, `d' for double, `?' for wildcard, and `s' for string. Because the Intel architecture is little-endian, the ASCII character occupies the first byte in memory (and the first one to be shipped over the network) and the other three bytes are zeroes. That sounds inefficient, but if I declare ``char tag'', the storage size for ``struct element'' is still 12 bytes. The knowledge that those three bytes are zeroes could, in future, be used to compress the network protocol. Since I'm only concerned with Linux running on Intel hardware, it's safe to say this is a four-byte little-endian field. Definition at line 131 of file tuple.h. Referenced by LinuxTuple_to_PyTuple, make_tuple_internal, print_element, PyTuple_to_LinuxTuple, recv_tuple, send_tuple, tuple_double_field, tuple_int_field, tuple_string_field, and tuples_match. |