Hi! I've been working on running PHP with undefined behavior sanitizer (http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html) and I've encountered a weird error while running PHP:
/src/php-src/Zend/zend_alloc.c:585:9: runtime error: shift exponent 138 is too large for 64-bit type 'zend_mm_bitset' (aka 'unsigned long') #0 0x86dada in zend_mm_bitset_is_set /src/php-src/Zend/zend_alloc.c:585:9 #1 0x86dada in zend_mm_bitset_is_free_range /src/php-src/Zend/zend_alloc.c:665 #2 0x86dada in zend_mm_realloc_heap /src/php-src/Zend/zend_alloc.c:1670 #3 0x86dada in _erealloc2 /src/php-src/Zend/zend_alloc.c:2577 Looks like the code is doing it intentionally: /* x86 instructions BT, SHL, SHR don't require masking */ #if defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__)) || defined(ZEND_WIN32) # define ZEND_BIT_TEST(bits, bit) (((bits)[(bit) / (sizeof((bits)[0])*8)] >> (bit)) & 1) #else # define ZEND_BIT_TEST(bits, bit) (((bits)[(bit) / (sizeof((bits)[0])*8)] >> ((bit) & (sizeof((bits)[0])*8-1))) & 1) #endif But I'm not sure how it's supposed to work. Is it correct that on GCC (and clang, presumably, since it defines __GNUC__) accept long bitshifts and do the right thing with argument like 138? Is it documented anywhere? Or is there a bug here? Thanks, -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php