log: escape C1 control characters in messages #36536

The log escapes control characters so that a message cannot drive the terminal it is printed on, but it lets through the UTF-8 form of the C1 controls U+0080 to U+009F. VTE, the library behind GNOME Terminal and others, decodes these as CSI, OSC, DCS and the rest, like their ESC [, ESC ] and ESC P forms.

I escape the two-byte sequences 0xC2 0x80 to 0xC2 0x9F as \xc2\x9b and so on. Since 0xC2 is never a continuation byte, this needs no UTF-8 decoder, and all other non-ASCII text still passes untouched, as asked in #17095 and #35833. Single bytes 0x80 to 0x9F stay as they are, since they occur inside valid UTF-8. The new cases in test_LogEscapeMessage fail on master and pass with the change.

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

External sites

• Code coverage & benchmarks: https://corecheck.dev/bitcoin/bitcoin/pulls/36536
• Ralph review <img src=https://review.fish.foo/assets/bitcoin/bitcoin/36536.png alt="Ralph review status"> https://git.fish.foo/bitcoin/bitcoin/pulls/36536#author-ralph

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline and AI policy for information on the review process.

If your review is incorrectly listed, please copy-paste <code>&lt;!--meta-tag:bot-skip--&gt;</code> into the comment that the bot should ignore.

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

No conflicts as of last run.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

ACK 40bb43f158bea7e2efdecff0e17d59d9bf32b924

tACK 40bb43f158bea7e2efdecff0e17d59d9bf32b924 test_LogEscapeMessage passes

tACK 40bb43f158bea7e2efdecff0e17d59d9bf32b924

Tested on Linux x86_64 (Ubuntu 24.04), g++ 13.3.0, Release: logging_tests pass, also with this branch merged onto current master (de96f3ae). With U+009B and U+009F in a regtest datadir path, debug.log has \xc2\x9b and \xc2\x9f on this branch and the raw bytes on the merge-base.

Nit: the two new checks don't independently pin down both boundaries. Changing the lower bound to >= 0x7f or the end check to i + 1 <= str.size() still passes them. The trailing \xc2 in the second check is a string literal, so str[str.size()] reads the terminating NUL.

Adding after line 141:

BOOST_CHECK_EQUAL(BCLog::LogEscapeMessage("\xc2\x7f"), "\xc2" R"(\x7f)");
BOOST_CHECK_EQUAL(BCLog::LogEscapeMessage(std::string_view{"\xc2\x9b", 1}), "\xc2");

Both pass on this branch. Each fails only with its corresponding mutant (lines 142 and 143, respectively; Debian 13 x86_64, GCC 14.2.0, Release).

Nit: the LogEscapeMessage doc comment and the test comment "ASCII and UTF-8 must pass through unaltered" don't mention the C1 exception. Also, U+0100 isn't adjacent to the tested range: that case checks a different lead byte followed by 0x80. The test itself is fine; only the comment is misleading.