As apparent in the title, I’m questioning the reason behind defining the macros inside a struct. I frequently see this approach in network programming for instance following snippet:
struct sniff_tcp {
u_short th_sport; /* source port */
u_short th_dport; /* destination port */
tcp_seq th_seq; /* sequence number */
tcp_seq th_ack; /* acknowledgement number */
u_char th_offx2; /* data offset, rsvd */
#define TH_OFF(th) (((th)->th_offx2 & 0xf0) >> 4)
u_char th_flags;
#define TH_FIN 0x01
#define TH_SYN 0x02
#define TH_RST 0x04
#define TH_PUSH 0x08
#define TH_ACK 0x10
#define TH_URG 0x20
#define TH_ECE 0x40
#define TH_CWR 0x80
#define TH_FLAGS (TH_FIN|TH_SYN|TH_RST|TH_ACK|TH_URG|TH_ECE|TH_CWR)
u_short th_win; /* window */
u_short th_sum; /* checksum */
u_short th_urp; /* urgent pointer */
};
This example is from sniffex.c code in tcpdump’s web site.
Is this for enhancing readability and making code clearer.
i think, this is no “best practice”, one should keep the defines (for values) near the struct, but not inside the struct.
(Even better would be to enum and typedef the constants, so a compiler could warn if not typed properly).
The TH_OFF() macro is another case, where it “hides” another element, so maybe it could be put at this position (with an appropriate comment)