Should TPACKET_ALIGNMENT be defined as 16U rather than just 16, to avoid undefined behavior warnings?

Should TPACKET_ALIGNMENT be defined as 16U rather than just 16, to avoid undefined behavior warnings?

[Guy Harris]

if_packet.h defines:

	#define TPACKET_ALIGNMENT	16
	#define TPACKET_ALIGN(x)	(((x)+TPACKET_ALIGNMENT-1)&~(TPACKET_ALIGNMENT-1))

Some compilers may, if TPACKET_ALIGN() is passed an unsigned value, give a warning that the result of converting ~(TPACKET_ALIGNMENT-1) to an unsigned int is undefined, as ~(TPACKET_ALIGNMENT-1) evaluates to -16 (0xFFFFFFF0), and C doesn't specify the behavior when converting negative values to an unsigned type.

In *practice*, with all the compilers we're likely to see, it just converts it to 4294967280U (0xFFFFFFF0), which is the desired behavior, but it might be cleaner (and produce fewer warnings when compiling code using TPACKET_ALIGN() or any of the macros using it) if TPACKET_ALIGNMENT were defined as 16U, rather than 16, as the entire computation will be done with unsigned integers.

netlink.h was changed to define NLMSG_ALIGNTO as 4U rather than 4, perhaps for the same reason.