+/*
+ * Data types corresponding to multi-byte integral values within data
+ * structures. These are defined as arrays of octets, so that they're
+ * not aligned on their "natural" boundaries, and so that you *must*
+ * use the EXTRACT_ macros to extract them (which you should be doing
+ * *anyway*, so as not to assume a particular byte order or alignment
+ * in your code).
+ */
+typedef unsigned char nd_uint16_t[2];
+typedef unsigned char nd_uint24_t[3];
+typedef unsigned char nd_uint32_t[4];
+typedef unsigned char nd_uint40_t[5];
+typedef unsigned char nd_uint48_t[6];
+typedef unsigned char nd_uint56_t[7];
+typedef unsigned char nd_uint64_t[8];
+
+/*
+ * Use this for IPv4 addresses. It's defined as an array of octets, so
+ * that it's not aligned on its "natural" boundary, and it's defined as
+ * a structure in the hopes that this makes it harder to naively use
+ * EXTRACT_BE_U_4() to extract the value - in many cases you just want
+ * to use UNALIGNED_MEMCPY() to copy its value, so that it remains in
+ * network byte order.
+ *
+ * (Among other things, we don't want somebody thinking "IPv4 addresses,
+ * they're in network byte order, so we want EXTRACT_BE_U_4(), right?"
+ * and then handing the result to system APIs that expect network-order
+ * IPv4 addresses, such as inet_ntop(), on their little-endian PCs, getting
+ * the wrong behavior, and concluding "oh, it must be in *little*-endian
+ * order" and "fixing" it to use EXTRACT_LE_U_4(). Yes, people do this;
+ * that's why Wireshark has tvb_get_ipv4(), to extract an IPv4 address from
+ * a packet data buffer; it was introduced in reaction to somebody who
+ * *had* done that.)
+ */
+typedef struct {
+ unsigned char bytes[4];
+} nd_ipv4;
+
+/*
+ * Data types corresponding to single-byte integral values, for
+ * completeness.
+ */
+typedef unsigned char nd_uint8_t;
+typedef signed char nd_int8_t;
+
projects / tcpdump / blobdiff