On 06/02/17 00:52, Rob Landley wrote:
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?
"may be used uninitialized" was notorious because the warning was
unreliable and naive fixes was potentially harmful (not least because
they blinded more advanced static analyzers from identifying real
algorithmic bugs).
This case has little similarity since the warnings is entirely reliable
and most fixes are clearly correct.
> 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?
We already know compilers use undefined behavior to make dead code
elimination passes more aggressive. We also know that this sometimes
reveals latent bugs in source code *and* that compiler research
continues! Where we find undefined behavior it should be fixed.
Daniel.
Signed-off-by: Rostislav Skudnov <[email protected]>
---
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
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
