A bug report filed against the Android Native Development Kit on October 14 describes a regression in Android 17 that can make two wide-character string functions treat almost every non-ASCII character as a match. The report says the problem appears in September 2026 builds and affects `wcscspn()` and `wcspbrk()` in Android's Bionic C library.
According to the reporter's tests on a Pixel 8a, the affected functions stop scanning when they encounter a character at or above U+0100 if the comparison set contains at least two ASCII characters. That is incorrect for `wcscspn()`, which should continue when the character is not in its reject set. Because `wcspbrk()` is built on the same scan, it inherits the behavior. Related functions including `wcsspn()`, `wcschr()` and `wcsstr()` were reported to behave correctly.
The test swept Unicode code points from U+0001 through U+10FFFF, excluding surrogate values and the two characters in the test set. The report says 1,111,808 code points, covering the range from U+0100 upward, produced the wrong result. That means software scanning wide strings for ASCII delimiters can fail when text contains emoji, CJK characters, Cyrillic, Greek or Latin Extended letters.
One concrete impact appeared in Visual Pinball's Wine-based VBScript component. Its lexer used `wcspbrk()` to find line endings in comments, so a comment containing an emoji could be treated as containing an invalid character. A separate path operation could interpret filenames containing non-ASCII characters as wildcard patterns. The downstream project replaced the affected calls with simple loops as a workaround.
The report also highlights a source-availability problem. Public Android 17 release code from June uses an LLVM libc implementation that the reporter found to be correct, while disassembly of the library shipped in the September build showed different logic. With source corresponding to the installed quarterly release unavailable, the reporter reconstructed the behavior from the binary to document the defect.
Existing test coverage helped explain why the regression escaped detection. The issue notes that an available `wcspbrk()` test used only ASCII input, which could not exercise the failing branch. The proposed additions use non-ASCII text and separately verify the complementary scanning functions, turning an application symptom into a focused platform regression case.
An Android project maintainer replied that the analysis appeared correct and that the problem was still present at the current development tip. The maintainer said missing tests would be added and a backport would be considered to reduce the number of affected devices. The exchange shows how delayed publication of matching platform source can complicate debugging even when developers provide a small reproducer, exhaustive measurements and a demonstrated application failure.
