svn commit: r296336 - in head/sys: dev/bhnd dev/pccard dev/pci isa kern sys x86/xen

[Bruce Evans]

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