On Sat, Oct 3, 2015 at 2:12 AM, Vadim Zhukov <z...@cvs.openbsd.org> wrote: > CVSROOT: /cvs > Module name: src > Changes by: z...@cvs.openbsd.org 2015/10/03 03:12:39 > > Modified files: > usr.bin/kdump : kdump.c > > Log message: > Fix wrong cast. > > This one should be an unsigned long in theory, but the formatter function > argument we're printing from is already an int (being casted from register_t > at the formatter call time). So lets fix one bug at a time.
To expand a bit on why the use of int vs long is not a problem here: the only thing using long gains is 32 more bits on LP64 archs. That's critical for pointers and buffer sizes, of course, where they really are limited to 32bit on ILP32 archs, but for enumeration and bitsets/flags like ioctl's 'request' argument, an enumeration value or flag bit >=2^32 would make that value impossible to use on ILP32 archs. Perhaps some day someone will come up with an ioctl() request that is legitimately specific to LP64 archs and can thus be safely assigned a request value >=2^32, but I don't foresee that and even then we would need to be running out of ioctl requests <2^32 to make it worth it. Until then, kdump can stick with ints for enumerations and flags, perhaps serve as a compilation check against someone breaking that rule accidentally. If a bitset/flag argument needs to exceed 32bits in an MD way, it should be typed as long long and thus be portably sized. Philip Guenther
