Use more the EXTRACT_U_1() macro (40/n)

[tcpdump] / netdissect.h

diff --git a/netdissect.h b/netdissect.h
index ec64cfe42ab51c6d5ab3dd66448d4aa3e3c4345d..2782796edc5f2e2167441bce331de0a2979e87d8 100644 (file)
--- a/netdissect.h
+++ b/netdissect.h
@@ -54,16 +54,16 @@ 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_32BITS() to extract the value - in many cases you just want
+ * 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_32BITS(), right?"
+ * 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_32BITS().  Yes, people do this;
+ * 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.)