[PATCH] Replace int -> uint to avoid signed integer overflow

[Rob Landley]

On 02/01/2017 12:35 PM, Rostislav Skudnov wrote:
> An example of such an error (should be compiled with DEBUG_SANITIZE):
> 
> runtime error: left shift of 1 by 31 places cannot be represented in
> type 'int'

Sure it can. We know exactly what bit pattern that represents in two's
complement, which has been the ubiquitous representation of negative
numbers since 1964.

Is this another "may be used uninitialized" thing where the compiler's
complaining about something that can't happen? Or have the C++ deveopers
who took over implementation of the C compiler broken yet another thing
that's universally worked since the 1960s because they want to extend
"undefined behavior" until C is as much of a minefield of special case
memorization as C++ is?

> Signed-off-by: Rostislav Skudnov <rostislav at tuxera.com>
> ---
>  archival/libarchive/decompress_bunzip2.c | 6 +++---
>  libbb/crc32.c                            | 2 +-
>  libbb/getopt32.c                         | 4 ++--
>  libbb/pw_encrypt.c                       | 2 +-
>  miscutils/rx.c                           | 2 +-
>  5 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/archival/libarchive/decompress_bunzip2.c b/archival/libarchive/decompress_bunzip2.c
> index fe5953d..4fb989c 100644
> --- a/archival/libarchive/decompress_bunzip2.c
> +++ b/archival/libarchive/decompress_bunzip2.c
> @@ -134,7 +134,7 @@ static unsigned get_bits(bunzip_data *bd, int bits_wanted)
>  
>  		/* Avoid 32-bit overflow (dump bit buffer to top of output) */
>  		if (bit_count >= 24) {
> -			bits = bd->inbufBits & ((1 << bit_count) - 1);
> +			bits = bd->inbufBits & ((1U << bit_count) - 1);

What's an archive input that actually fails? What's an example of a
processor machine language that doesn't produce 0x80000000 for 1<<31?

Where does this actually cause a problem?

Rob