Java treats strings differently than C does. In Java, null characters are allowed. In C, they end the string. So if we inline a Java string that contains null characters as a literal, the SQL parsing will just fail when Android passes it to the native SQLite library. Of course, the best option is to bind all such strings as arguments rather than inlining them, but when there are too many arguments (like in a large IN criterion), we fall back to inlining, so we need a fallback for inlined string literals too. This commit enhances string literal sanitization to replace occurrences of null characters with SQL string concatenations of CAST(x'00' AS TEXT), which converts a literal blob of the null character to a string.
LGTM. Might be nice to add something to entice devs to avoid writing statements that exceed the sqlite args limit, but i wouldn't consider that blocking.
Java treats strings differently than C does. In Java, null characters are allowed. In C, they end the string. So if we inline a Java string that contains null characters as a literal, the SQL parsing will just fail when Android passes it to the native SQLite library. Of course, the best option is to bind all such strings as arguments rather than inlining them, but when there are too many arguments (like in a large IN criterion), we fall back to inlining, so we need a fallback for inlined string literals too. This commit enhances string literal sanitization to replace occurrences of null characters with SQL string concatenations of CAST(x'00' AS TEXT), which converts a literal blob of the null character to a string.