Fixes warning about 64-bit literals on 32-bit platforms.

An unadorned 64-bit literal provokes a width warning on 32-bit
platforms.  Depending on whether the compiler promotes such literals
to a 64-bit type, this case could represent an actual malfunction.
The fix is simply to use the "LL" suffix (actually "ULL" in these
cases).

This also switches to ~0 as the all-ones mask, for better readability.

It also changes a nearby "1LL" to "1ULL" for consistency with its
unsigned context.

TESTED:
Ran "scons build-all check" on four versions of OSX, two versions of
Linux, and FreeBSD, OpenBSD, and NetBSD, with two cases being 32-bit.

1 files changed, 4 insertions, 4 deletions

diff --git a/bits.c b/bits.c
index 8cbabc57..2f7739cc 100644
--- a/bits.c
+++ b/bits.c
@@ -37,7 +37,7 @@ uint64_t ubits(unsigned char buf[], unsigned int start, unsigned int width, bool
 	fld >>= (CHAR_BIT - end);
     }
 
-    fld &= ~(0xffffFFFFffffFFFF << width);
+    fld &= ~(~0ULL << width);
 
     /* was extraction as a little-endian requested? */
     if (le)
@@ -63,12 +63,12 @@ int64_t sbits(signed char buf[], unsigned int start, unsigned int width, bool le
     uint64_t fld = ubits((unsigned char *)buf, start, width, le);
 
     /* ensure width > 0 as the result of
-       1LL << (width - 1)
+       1ULL << (width - 1)
        is undefined for width <= 0 */
     assert(width > 0);
 
-    if (fld & (1LL << (width - 1))) {
-	fld |= (0xffffffffffffffff << (width - 1));
+    if (fld & (1ULL << (width - 1))) {
+	fld |= (~0ULL << (width - 1));
     }
     return (int64_t)fld;
 }