lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:   Sat, 7 Dec 2019 21:29:45 -0800
From:   Guy Harris <guy@...m.mit.edu>
To:     netdev <netdev@...r.kernel.org>
Subject: Should TPACKET_ALIGNMENT be defined as 16U rather than just 16, to
 avoid undefined behavior warnings?

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.

Powered by blists - more mailing lists