8000 log: replace NUL bytes in a message instead of panicking by benface · Pull Request #685 · not-fl3/miniquad · GitHub
[go: up one dir, main page]

Skip to content

log: replace NUL bytes in a message instead of panicking - #685

Open
benface wants to merge 1 commit into
not-fl3:masterfrom
benface:log-nul-bytes
Open

benface wants to merge 1 commit into
not-fl3:masterfrom
benface:log-nul-bytes

Conversation

@benface
@benface benface commented Oct 10, 2026
Copy link
Copy Markdown
Contributor

Why

On Android and wasm, __private_api_log_lit turns the message into a C string with CString::new(message).unwrap_or_else(|_| panic!()). So a message holding a NUL byte panics inside warn! or error!, with no message of its own, and never reaches the log. That happens whenever a message quotes data the app doesn't control, such as a parse error quoting a corrupt file:

E SAPP    : panicked at src/log.rs:226:56:
E SAPP    : explicit panic

Change

A c_string helper replaces each NUL with U+FFFD, the replacement character, before building the C string, so the rest of the message still reaches the log. The Android and wasm paths both use it, and a test covers the replacement.

Verification

  • On the Android emulator (API 35), a macroquad game (CHOMP) whose save file held NUL bytes panicked at launch when it logged the parse error with warn!. With this change, Logcat shows the warning with � where the NULs were, and the game carries on.
  • cargo test --features log-impl passes on macOS, new test included.
  • cargo check --features log-impl passes for aarch64-linux-android and wasm32-unknown-unknown. I didn't run the wasm path in a browser.

🤖 Generated with Claude Code

Android's log and the browser's console take C strings, and
`__private_api_log_lit` built them with
`CString::new(message).unwrap_or_else(|_| panic!())`. So a message
holding a NUL byte panicked inside `warn!` or `error!`, with no
message of its own, and never reached the log. That happens whenever
a message quotes data the app doesn't control, such as the text of a
file it failed to parse.

Each NUL is now replaced with U+FFFD, the replacement character, so
the rest of the message still reaches the log.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

0