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.
David
--
David Laight: da...@l8s.co.uk
