Date: Thu, 3 Mar 2016 17:18:38 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Justin Hibbits <jhibbits@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r296336 - in head/sys: dev/bhnd dev/pccard dev/pci isa kern sys x86/xen Message-ID: <20160303164728.W1928@besplex.bde.org> In-Reply-To: <201603030507.u2357ae2098576@repo.freebsd.org> References: <201603030507.u2357ae2098576@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160303164728.W1928>