Repository navigation
Snappy.maxCompressedLength can return a negative size #671
Description
This is applicable to snappy-java-1.1.10.7.jar.
bash-3.2$ jshell --class-path /Users/<redacted>/jars/snappy-java-1.1.10.7.jar
| Welcome to JShell -- Version 21.0.6
| For an introduction type: /help intro
jshell> import org.xerial.snappy.Snappy;
import org.xerial.snappy.Snappy;
jshell> Snappy.maxCompressedLength(1840700246);
Snappy.maxCompressedLength(1840700246);
$2 ==> -2147483644
jshell>
This could very well be an appropriate response. But I wanted to verify before I file an issue with a second library which assumes that the result of Snappy.maxCompressedLength is always usable as a buffer size.
Activity
bersprockets commentedon Jul 14, 2025
This seems to be an interaction between the underlying native code and the Java's lack of unsigned integer. The code does this calculation, where
source_byteshas thesize_ttype:When
source_bytesis 1840700246, the result of that calculation is 2147483652 (or 0x80000004). When cast to anint, this ends up as -2147483644.Validate maxCompressedLength and stream array ranges (#741)
xerial commentedon Oct 3, 2026
Fixed in #741 (merged). Snappy.maxCompressedLength now throws SnappyError(TOO_LARGE_INPUT) when the result would overflow int (n >= 1,840,700,243) instead of returning a negative size, so callers can always use a returned value as a buffer size. Ships in 1.1.10.9.