AOSP Source Releases Are So Late Developers Disassemble Libraries to Report Bugs

[BUG] bionic: wcscspn()/wcspbrk() treat every wchar_t >= 0x100 as a match (Android 17, CP3A.260905.009) #2260 Description Description On Android 17 builds from September 2026, wcscspn() and wcspbrk() stop at the first character of the string that is >= U+0100 whenever the reject set has two or more characters that are all < U+0100. The character is reported as a match even though it is not in the set. wcsspn(), wcschr(), wcsrchr(), wmemchr() and wcsstr() are correct. Any code that scans wide strings for ASCII delimiters, for example newline or wildcard characters, breaks as soon as the text contains an emoji, CJK, Cyrillic, Greek or Latin Extended character. Affected / unaffected The public android17-release sources (android-17.0.0_r1, June 2026) build wcscspn/wcspbrk from external/llvm-libc, which is a plain nested loop over wchar_t and is correct. The code on the September builds is different (see "Mechanism"), so the regression was introduced between the June and September releases. Reproducer Build with the NDK (aarch64-linux-android30-clang), push to /data/local/tmp, run with adb shell: #include #include int main(void) { wchar_t s[] = {'a', 0x1F680, 0x100, 'b', 'x', '\n', 0}; printf("wcscspn(s, L\"x\\n\") = %zu (expected 4)\n", wcscspn(s, L"x\n")); printf("wcspbrk(s, L\"x\\n\") = index %ld (expected 4)\n", (long)(wcspbrk(s, L"x\n") - s)); printf("wcsspn(s, L\"a\\U0001F680\") = %zu (expected 2)\n", wcsspn(s, L"a\U0001F680")); return 0; } Output on CP3A.260905.009: wcscspn(s, L"x\n") = 1 (expected 4) wcspbrk(s, L"x\n") = index 1 (expected 4) wcsspn(s, L"a\U0001F680") = 2 (expected 2) A sweep of every code point from U+0001 to U+10FFFF (skipping surrogates and the two set members) with wcscspn(L" \n", L"x\n") returns 0 instead of 1 for 1,111,808 code points: every one from U+0100 to U+10FFFF. U+0001 to U+00FF are correct. Which set shapes trigger it (all measured on the Pixel 8a): Mechanism (from the shipped libc.so) Disassembly of wcscspn in /apex/com.android.runtime/lib64/bionic/libc.so on CP3A.260905.009 shows three paths selected by the set: One character: a plain compare loop. Correct. Two or more characters: a 256-byte bool table on the stack is filled from the set while the set characters are in 1..0xFF. If a set character >= 0x100 is seen, the function falls back to calling wcschr() for each haystack character. Correct. Otherwise the haystack is scanned against the table: a2564: ldrb w8, [x9, x8] ; table[c] a2568: tbnz w8, #0, a2578 ; in set -> stop (correct) a256c: ldr w8, [x22, #0x4]! ; next character a2570: cmp w8, #0x100 a2574: b.lo a2564 ; c < 0x100 -> keep scanning a2578: ... ; c >= 0x100 -> STOP, reported as a match A character >= 0x100 cannot be in a set whose members are all < 0x100, so for wcscspn the scan must continue past it. The code stops instead. wcsspn has the same structure, and there stopping is the correct answer (the character is not in the keep set), which is why only the complement functions are wrong. wcspbrk is implemented on top of this scan and inherits the bug. The existing bionic test TEST(wchar, wcspbrk) in tests/wchar_test.cpp only uses ASCII input, so it does not catch this. A test such as EXPECT_EQ(3u, wcscspn(L"aĀb\n", L"x\n")) would. Real-world impact Visual Pinball on Android (libwinevbs, a Unix build of Wine's vbscript engine) stopped loading any table whose VBScript source contains a comment with an emoji after the September update: the lexer uses wcspbrk(ptr, L"\n\r") to skip comments, got the position of the first emoji instead of the line end, and reported "Invalid character". FileSystem.MoveFolder likewise treated every path containing a character >= U+0100 as a wildcard pattern via wcspbrk(src, L"*?><"). Worked around downstream by replacing the calls with plain loops: vpinball/libwinevbs#41 (shipped in vpinball/vpinball@e7837322f4). Full disassembly of the affected functions and the probe sources are available on request. I am using a supported NDK I have checked and the NDK I'm using is currently supported Affected versions r29 Activity francisdb added bug on Oct 12, 2026 enh-google commented on Oct 12, 2026 enh-google on Oct 12, 2026 Collaborator More actions yeah, that all sounds correct, and seems to still be an issue at ToT. (i was going to say "you know you can just look at the source?", but android-latest-release seems to still be too old to have any of these changes from april :-( ) wcspbrk() is affected because it's just __attribute__((__flatten__)) wchar_t* wcspbrk(const wchar_t* s, const wchar_t* delims) { size_t i = wcscspn(s, delims); if (s[i] != L'\0') return const_cast (s) + i; return nullptr; } but i'll add both missing tests, and ideally try to see if i can find everywhere else we're missing a test that actually uses non-ascii! i'll also see if i can get the fix backported to minimize the number of affected devices. (which is probably a reason to ensure any not-directly-related tests are added in a separate later change.) 😕React with 😕8Reacted by Joaquín Vacas Verísimo, Kunal Agrawal, Vinayak, Doug Lynch, Matheus Araújo, David Allison, LifeIsStrange and JannF 👀React with 👀3Reacted by Joaquín Vacas Verísimo, Doug Lynch and David Allison enh-google commented on Oct 12, 2026 yeah, that all sounds correct, and seems to still be an issue at ToT. (i was going to say "you know you can just look at the source?", but android-latest-release seems to still be too old to have any of these changes from april :-( ) wcspbrk() is affected because it's just __attribute__((__flatten__)) wchar_t* wcspbrk(const wchar_t* s, const wchar_t* delims) { size_t i = wcscspn(s, delims); if (s[i] != L'\0') return const_cast (s) + i; return nullptr; } but i'll add both missing tests, and ideally try to see if i can find everywhere else we're missing a test that actually uses non-ascii! i'll also see if i can get the fix backported to minimize the number of affected devices. (which is probably a reason to ensure any not-directly-related tests are added in a separate later change.) enh-google commented on Oct 12, 2026 enh-google on Oct 12, 2026 Collaborator More actions gah, even more embarrassing is that we do have an existing test for wcscspn(), it's just wrong: [ RUN ] wchar.wcscspn bionic/tests/wchar_test.cpp:(1475) Failure in test wchar.wcscspn Expected equality of these values: 2u Which is: 2 wcscspn(L"he\ufffelo", L"lo") Which is: 3 wchar.wcscspn exited with exitcode 1. 🤦 😕React with 😕1Reacted by Joaquín Vacas Verísimo 👀React with 👀1Reacted by Joaquín Vacas Verísimo enh-google commented on Oct 12, 2026 gah, even more embarrassing is that we do have an existing test for wcscspn(), it's just wrong: [ RUN ] wchar.wcscspn bionic/tests/wchar_test.cpp:(1475) Failure in test wchar.wcscspn Expected equality of these values: 2u Which is: 2 wcscspn(L"he\ufffelo", L"lo") Which is: 3 wchar.wcscspn exited with exitcode 1. 🤦 francisdb commented on Oct 13, 2026 francisdb on Oct 13, 2026 Author More actions Thanks for the quick response. It's indeed unfortunate that the source is not available (yet). francisdb commented on Oct 13, 2026 Thanks for the quick response. It's indeed unfortunate that the source is not available (yet). joaquinvacas commented on Oct 13, 2026 joaquinvacas on Oct 13, 2026 More actions Sorry if it sounds dramatic, because it's not. I'm just worried. Something feels wrong with this... Since Google decided to close AOSP source code, a lot of issues have been flourishing without any kind of fix, and there's no transparency from the Google part... Is there any movement regarding how this is going to be managed? I mean, not this bug, but the issues regarding the management of the AOSP project. 👍React with 👍15Reacted by MasterMann, Marcin Panniak, Terence Eden, Ben Parsons, p12h4, Björn Kettunen, Marcos Del Sol Vives, Braden Farmer, Max Rumpf, Agustín and 5 more joaquinvacas commented on Oct 13, 2026 Sorry if it sounds dramatic, because it's not. I'm just worried. Something feels wrong with this... Since Google decided to close AOSP source code, a lot of issues have been flourishing without any kind of fix, and there's no transparency from the Google part... Is there any movement regarding how this is going to be managed? I mean, not this bug, but the issues regarding the management of the AOSP project. pirama-arumuga-nainar commented on Oct 13, 2026 pirama-arumuga-nainar on Oct 13, 2026 Collaborator More actions Is there any movement regarding how this is going to be managed? I mean, not this bug, but the issues regarding the management of the AOSP project. source.android.com (in particular, https://source.android.com/docs/whatsnew/site-updates?year=2026#aosp-changes) has official communication on this topic. (i was going to say "you know you can just look at the source?", but android-latest-release seems to still be too old to have any of these changes from april :-( ) FWIW, android-latest-release is a manifest branch, and android17-release is the git branch. The android 17 sources for bionic are in https://android.googlesource.com/platform/bionic/+/refs/heads/android17-release. pirama-arumuga-nainar commented on Oct 13, 2026 Is there any movement regarding how this is going to be managed? I mean, not this bug, but the issues regarding the management of the AOSP project. Is there any movement regarding how this is going to be managed? I mean, not this bug, but the issues regarding the management of the AOSP project. source.android.com (in particular, https://source.android.com/docs/whatsnew/site-updates?year=2026#aosp-changes) has official communication on this topic. (i was going to say "you know you can just look at the source?", but android-latest-release seems to still be too old to have any of these changes from april :-( ) (i was going to say "you know you can just look at the source?", but android-latest-release seems to still be too old to have any of these changes from april :-( ) FWIW, android-latest-release is a manifest branch, and android17-release is the git branch. The android 17 sources for bionic are in https://android.googlesource.com/platform/bionic/+/refs/heads/android17-release. zenczykowski commented on Oct 13, 2026 zenczykowski on Oct 13, 2026 More actions Yes, but where is the source code for Android 17 QPR1 which is what is actually running on Pixel and has been stable for over a month... 👍React with 👍2Reacted by TangerineNightmare and qouteall zenczykowski commented on Oct 13, 2026 Yes, but where is the source code for Android 17 QPR1 which is what is actually running on Pixel and has been stable for over a month... francisdb commented on Oct 13, 2026 francisdb on Oct 13, 2026 Author More actions There must be a better location to discuss these general issues? 👍React with 👍1Reacted by David Allison francisdb commented on Oct 13, 2026 There must be a better location to discuss these general issues? Metadata Metadata Assignees Labels Type Projects Milestone Relationships Development Issue actions Open in GitHub Copilot app