Undefined behaviour on 32-bit platforms

[sjakobi]

unordered-containers/Data/HashMap/Internal.hs

Lines 2258 to 2261 in 63ec59a

	-- | A bitmask with the 'bitsPerSubkey' least significant bits set.
	fullNodeMask :: Bitmap
	fullNodeMask = complement (complement 0 `unsafeShiftL` maxChildren)
	{-# INLINE fullNodeMask #-}

The docs for unsafeShiftL say:

Shift the argument left by the specified number of bits. The
result is undefined for negative shift amounts and shift amounts
greater or equal to the 'bitSize'.

With maxChildren being 32 since #317, the value of fullNodeMask seems to be subject to UB on 32-bit platforms.

[sjakobi]

I haven't found any other UB related to unsafeShift{L,R}.

For index, we can document the bounds on the Shift argument though.

unordered-containers/Data/HashMap/Internal.hs

Lines 2252 to 2256 in 63ec59a

	-- | Mask out the 'bitsPerSubkey' bits used for indexing at this level
	-- of the tree.
	index :: Hash -> Shift -> Int
	index w s = fromIntegral $ unsafeShiftR w s .&. subkeyMask
	{-# INLINE index #-}

[treeowl]

Do things work out if we manually set the value to -1, or do other bitwise operations go screwy for other reasons? If a branching factor of 32 is problematic on 32-bit architectures, can't we just set it back to 16 for them?

[sjakobi]

Do things work out if we manually set the value to -1, or do other bitwise operations go screwy for other reasons?

I think some operations expect the "empty bitmap" to be 0, for example the loop in unionArrayBy.

To fix this issue, I'd try using shiftL instead of unsafeShiftL.