Skip to content

Fix inline_string_encode and inline_string_decode#576

Merged
arch1t3cht merged 5 commits intoTypesettingTools:masterfrom
filip-hejsek:inline_decode_fix
Mar 17, 2026
Merged

Fix inline_string_encode and inline_string_decode#576
arch1t3cht merged 5 commits intoTypesettingTools:masterfrom
filip-hejsek:inline_decode_fix

Conversation

@filip-hejsek
Copy link
Contributor

  • Fix incorrect escape decoding, which among other things caused extradata corruption
  • Fix Unicode chars being unnecessarily escaped when char is signed
  • Move string_codec.cpp to libaegisub so that it can be tested
  • Add tests for encoding and decoding
  • Remove an unrelated unused include which I noticed while working on this

@filip-hejsek filip-hejsek changed the title Fix inline_string_encode and inline_string_encode Fix inline_string_encode and inline_string_decode Mar 16, 2026
Copy link
Member

@arch1t3cht arch1t3cht left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! LGTM except one small nit and the failing Windows CI, which looks like a missing #include <string> in string_codec.h.

@filip-hejsek
Copy link
Contributor Author

I addressed the nit and added the missing include, let's see if the CI passes now.

Before moving string_codec to libaegisub, it worked without the include, which seems to be because:

  • On Linux, #include <string_view> brings in a forward declaration of std::string
  • The Winsows CI build has PCH enabled, and agi_pre.h (but not lagi_pre.h) pulls in <string>

Maybe include-what-you-use could help clean up includes in the codebase?

@filip-hejsek
Copy link
Contributor Author

Oops, I accidentally amended the wrong commit, let me fix that

@arch1t3cht
Copy link
Member

Thanks!

Maybe include-what-you-use could help clean up includes in the codebase?

Yes, definitely. There's a bunch of static analysis tooling that I'd like to set up eventually but haven't gotten to yet.

It might also (or additionally) be an option to just also disable PCHs on the Windows and Mac CI. This wasn't done originally in #303 because the Windows CI already takes a very long time, but I since realized that the vast majority of time is spent compiling dependencies rather than Aegisub itself. So disabling PCHs for Aegisub would not have that much of an impact on the CI runtime.

@arch1t3cht arch1t3cht merged commit 05b6e95 into TypesettingTools:master Mar 17, 2026
7 checks passed
@filip-hejsek filip-hejsek deleted the inline_decode_fix branch March 17, 2026 14:24
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.

2 participants