On Thu, 3 Mar 2016, Justin Hibbits wrote:
Log:
Replace all resource occurrences of '0UL/~0UL' with '0/~0'.
Summary:
The idea behind this is '~0ul' is well-defined, and casting to uintmax_t, on a
32-bit platform, will leave the upper 32 bits as 0. The maximum range of a
resource is 0xFFF.... (all bits of the full type set). By dropping the 'ul'
suffix, C type promotion rules apply, and the sign extension of ~0 on 32 bit
platforms gets it to a type-independent 'unsigned max'.
Why not use the correct signed value? This value is -1, not the value, if
any, with all bits 1. All bits 1 might be a trap representation, but it
is unclear if ~0 can give a trap representation or a trap since it is
unclear if the '~' operation acts on padding bits. It is clear that all
bits 1 gives has value -0 in 1's complement if there are no no padding
bits. But -0 has the same value as +0. When converted to an unsigned
type, it loses all traces of its sign, and becomes plain (ufoo_t)0.
I don't like the plan to change the resource range type to uintmax_t.
64 bits is just bloat for most 32-bit systems. After fixing all the
hard-coded u_longs, you can just use a typdefed type which should be
uint32_t if possible.
Bruce
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
