Every Emoji Became a Delimiter: The Fast Path That Guarded the Wrong Variable

Somewhere inside Android's C library, there's a loop that turns every emoji into a line break. Not literally — the bytes are untouched. But when an app asks "where does this line end?", the library points at the first character above U+00FF and says "right here."

This is not a story about Unicode being hard. It's a story about a fast path that checked the wrong variable, and a test suite that only spoke ASCII, so the mistake survived a release.

What broke

In October, a developer filed issue #2260 against Android's NDK. Two functions in bionic — Android's libc, the standard C library every native app links against — were wrong on the September 2026 Android 17 builds: wcscspn() and wcspbrk(). Both operate on wide strings, the kind that hold text beyond ASCII.

You don't need the C details, just the shape of it. wcspbrk(s, delimiters) asks: give me the first character in s that also appears somewhere in delimiters. Lexers and parsers ask that question constantly — find the next newline, find the next wildcard, find where this token ends.

On the affected builds, whenever the delimiter set contained two or more characters and all of them were below U+0100 (roughly: plain ASCII), every character above U+00FF was reported as a match. The reporter swept every code point from U+0001 to U+10FFFF and found 1,111,808 wrong answers — every single one from U+0100 upward. Below U+0100, everything was correct.

The failure that surfaced it is wonderfully mundane. Visual Pinball on Android stopped loading any table whose VBScript source contained an emoji in a comment. Wine's VBScript engine uses wcspbrk to skip to the end of a line. It got the position of the emoji instead, and told the user "Invalid character."

The bug in one sentence

The disassembly gives the mistake a name. When the delimiter set has two or more characters, the function takes a fast path: build a 256-byte table with one slot per byte value, mark the delimiters in it, then scan the string one character at a time against that table.

There's a guard on that scan: if the character is below 0x100, look it up in the table; otherwise, stop. The table can only represent the first 256 code points, so the guard is a reasonable optimization. The bug is in what stopping means. For wcscspn — "count the characters before the first delimiter" — a character that can't be in the table certainly can't be a delimiter, so the scan has to continue past it. The code stopped instead, and reported a match.

Now notice what the code did check. Before entering the fast path, it inspected the delimiter set: if any delimiter was at or above U+0100, it bailed out to a slower, correct implementation. The author was thinking about Unicode. They just guarded the wrong variable. The needles were ASCII, so the table looked safe — but the haystack wasn't.

You validated the needle and forgot the haystack. That sentence is the bug.

Why no test caught it

A bug that survives to a release usually has a narrow trigger, and this one's is almost comically specific. Break it down:

• One delimiter, any value: correct. A single-character set uses a simple compare loop.
• Two or more delimiters, all below U+0100: broken. This is the fast path.
• Two or more, at least one at or above U+0100: correct. It falls back to the slow path.
• Haystack limited to U+0080–U+00FF: correct. Every character still fits in the table.

Read that list again from the perspective of a test author. The bug appears when the code is written in the most ordinary way possible (a delimiter set of plain ASCII) and the data is the thing that's unusual. The existing tests for this family of functions in bionic use ASCII input only. The reporter's suggested addition is exactly one line: expect 3 from wcscspn(L"aĀb\n", L"x\n").

The general lesson isn't "add Unicode tests." It's that your fixtures encode the world the code was written for. When the bug is "the code assumed its own normal case," tests built from the same assumption can't see it.

Two functions, one loop, opposite answers

Here's the part I'd steal. wcsspn counts the leading characters that are in a set. wcscspn counts the leading characters that are not. The shipped code used the same scan structure for both — and for wcsspn, stopping on a character above 0x100 is correct, because such a character can't be in a set made of ASCII. Same branch. Opposite meaning.

That gives you two assertions that would have failed on the first emoji:

1. Exactly one of the two counts is nonzero. The initial run of a string goes one way or the other; it can't go both.
2. The index wcscspn returns must point at a character that is genuinely in the set. On the broken build, wcspbrk(L"a🚀b\n", L"x\n") returned index 1 — and the character at index 1 is not in the set. One assertion, one failed run, one fixed bug.

Generalize that. Whenever you write a positive and a negative version of the same operation — allow and deny, include and exclude, find and find-not — assert the relationship between them. Don't test each one against examples you made up. Test that they agree about the same input.

The workaround is the cost you actually pay

The fix landed in two places. Downstream, the Visual Pinball project replaced the calls with hand-written loops — correct, marginally slower, shipped. Upstream, an Android collaborator confirmed the bug was still present at the tip of the tree and said they'd add both missing tests.

Both responses are reasonable. But look at the shape of it: the correct implementation lived in a video-game repository as a workaround, while the platform shipped wrong. If you run an engineering org, that's a number worth measuring. How many local shims does your platform have, and how old are they? Every workaround is a bug report that was either filed and forgotten, or never filed at all. Count yours this quarter. It's a cheap audit with an uncomfortable payoff.

A checklist you can run this week

1. List every lookup table, bitmask, or precomputed index in your hot path. For each one, finish the sentence: "this handles everything except ___."
2. Find the code that handles the blank. If the answer is "stop," "return matches," or "assume valid," you've found a candidate. The blank is where the assumption lives.
3. Guard the input, not the configuration. Checking that your needle is ASCII does nothing for the haystack. Either check the data you're scanning, or make the fallback per-character instead of all-or-nothing.
4. Sweep, don't sample. When the domain is enumerable — 256 byte values, 1.1 million code points, HTTP status codes, your own enum — iterate all of it in a test. The reporter's full sweep is one loop, runs in seconds, and found over a million failures.
5. Assert complements, not examples. Two functions that partition an input should say so out loud, and the test should check the claim rather than a fixture.

Where AI code generation fits

It makes this bug cheaper to write and harder to spot. Ask a model to "skip to the end of the line," and you'll get a loop with an ASCII assumption, because the assumption is correct in the ticket and false in the data. The tests it writes next to that code will use the same idiom — ASCII fixtures, examples rather than properties. That isn't a model failure. It's what any author does when nothing forces them to consider the exotic case.

What helps is a prompt that targets the assumption instead of the implementation: here is the code. List every assumption it makes about its input, and for each one, describe what happens when it's false. Then write the test that breaks it. This is the kind of review that doesn't scale by reading faster. As code volume climbs across the industry — Anthropic has written about merging 30,000 changes a day, which pushed the bottleneck from writing code to reviewing it — the reviews worth a human's time are the ones that question the shape of the assumption. A checker can find the syntax error. It can't tell you that your table quietly redefined what a delimiter is.

Key Takeaways

• Android's libc reported every code point above U+00FF as a delimiter when the delimiter set held two or more ASCII characters — 1,111,808 wrong answers, found by a full code-point sweep.
• The table wasn't the bug. The guard was. The fast path validated the needle (ASCII delimiters) and said nothing about the haystack (arbitrary user text).
• The same early-exit branch was correct for wcsspn and wrong for its complement, wcscspn. Complementary operations need relationship tests, not example tests.
• Tests built from the code's own assumptions can't catch an assumption bug. Sweep enumerable domains exhaustively; it's cheap and it runs in seconds.
• Downstream shims are platform bugs you're paying rent on. Count them, then fix the platform instead of the app.
• When you use a model to write parsers, ask it to list its input assumptions before you ask it for a test. Review the assumption, not the syntax.