10月14日にAndroid Native Development Kitに対して提出された不具合報告は、Android 17のリグレッションにより、2つのワイド文字列関数がほぼすべての非ASCII文字を一致と判定してしまう可能性を指摘している。報告によると、この問題は2026年9月のビルドで発生し、AndroidのBionic Cライブラリにある`wcscspn()`と`wcspbrk()`に影響する。

報告者がPixel 8aで行ったテストによると、比較対象の文字集合にASCII文字が2つ以上含まれている場合、問題の関数はU+0100以上の文字に遭遇すると走査を停止する。これは、除外対象の文字集合に含まれない文字であれば走査を続けるべき`wcscspn()`の動作としては誤りだ。`wcspbrk()`も同じ走査処理を基に実装されているため、この挙動を引き継ぐ。一方、関連する`wcsspn()`、`wcschr()`、`wcsstr()`などの関数は正しく動作したと報告されている。

テストでは、サロゲート値とテスト用の集合に含まれる2文字を除き、U+0001からU+10FFFFまでのUnicodeコードポイントを網羅的に調べた。報告では、U+0100以上の範囲にある1,111,808個のコードポイントで誤った結果が得られたとしている。つまり、ASCIIの区切り文字を探すためにワイド文字列を走査するソフトウェアは、テキストに絵文字、CJK文字、キリル文字、ギリシャ文字、ラテン拡張文字が含まれていると処理に失敗する可能性がある。

具体的な影響の一つは、Visual PinballのWineベースのVBScriptコンポーネントで現れた。その字句解析器はコメント内の行末を見つけるために`wcspbrk()`を使っていたため、絵文字を含むコメントが不正な文字を含むものとして扱われる可能性があった。別のパス処理では、非ASCII文字を含むファイル名がワイルドカードパターンとして解釈される可能性もあった。この下流プロジェクトは、回避策として問題の関数呼び出しを単純なループに置き換えた。

報告は、ソースを入手できないという問題も浮き彫りにしている。6月に公開されたAndroid 17のリリースコードはLLVM libcの実装を使っており、報告者はその動作が正しいことを確認した。一方、9月のビルドに同梱されたライブラリを逆アセンブルすると、異なるロジックが見つかった。インストール済みの四半期リリースに対応するソースが入手できなかったため、報告者はバイナリから挙動を再構成して不具合を記録した。

既存のテスト範囲を見ると、なぜこのリグレッションが検出を免れたのかも分かる。報告は、利用可能な`wcspbrk()`のテストがASCII入力しか使っておらず、問題のある分岐を実行できなかったと指摘している。提案された追加テストは非ASCIIテキストを使い、補完関係にある走査関数も個別に検証する。これにより、アプリケーションで生じた症状を、プラットフォームの特定のリグレッションを検証する事例へと落とし込んでいる。

Androidプロジェクトのメンテナーは、この分析は正しいと思われ、現在の開発先端版にも問題が残っていると返信した。メンテナーは、不足しているテストを追加し、影響を受ける端末を減らすためにバックポートを検討すると述べた。このやり取りは、開発者が小さな再現プログラム、網羅的な測定結果、実際に確認したアプリケーションの不具合を提示しても、対応するプラットフォームのソース公開が遅れるとデバッグが複雑になり得ることを示している。