On Thu, Mar 22, 2012 at 07:27:18 +0000, David Laight wrote: > On Wed, Mar 21, 2012 at 11:57:25PM +0100, Nicolas Joly wrote: > > On Wed, Mar 21, 2012 at 10:42:58PM +0200, Alan Barrett wrote: > > > On Wed, 21 Mar 2012, Havard Eidnes wrote: > > > >Modified Files: > > > > src/lib/libc/arch/alpha/gen: fpgetround.c fpsetround.c > > > > > > > >Log Message: > > > >Add some casts to get rid of "bitwise op on signed value is non-portable" > > > >warning from lint. > > > > > > I see no bitwise ops on signed values here. > > > > > > >- return ((fpcrval.u64 >> 58) & 0x3); > > > >+ return ((fp_rnd)(fpcrval.u64 >> 58) & 0x3); > > > > > > fpcrval.u64 is uint64_t. After the "integer promotions", > > > it's still uint64_t (unless that's smaller than int, which is not > > > the case for any existing NetBSD port). After >>58, it's still > > > uint64_t. 0x3 is a signed int, but the "usual arithmetic conversions" > > > should convert it to uint64_t. > > > > The commit message reference the wrong lint warning. > > > > /local/src/NetBSD/src/lib/libc/arch/alpha/gen/fpgetround.c(61): warning: > > conversion from 'unsigned long' to 'enum <unnamed>' may lose accuracy [132] > > /local/src/NetBSD/src/lib/libc/arch/alpha/gen/fpsetround.c(61): warning: > > conversion from 'unsigned long' to 'enum <unnamed>' may lose accuracy [132] > > Which is bogus because of the '& 3' which brings the value inside valid > range. > > The cast is really in the wrong place as well. > > I am 100% against adding casts of numeric values to appease a tool that > isn't tracking the domains of the expressions.
Me too. Code becomes very hard to read when bit dances in complex expressions are hidden behind casts and in some cases all of that is sliced into a word-per-line word salat to fit into 80 columns (b/c the cast now consumes more than half of the available line length). -uwe
