text-freetype2: Track text length explicitly to permit embedded null bytes

[4RH1T3CT0R7]

Description

When 'Read from file' is enabled, files containing embedded null bytes are truncated at the first null because strlen() treats it as end-of-string. This causes only partial file content to display.

Approach

Instead of stripping null bytes (as in the initial version of this PR), this now follows the explicit length-tracking approach discussed in #11045:

• Added text_len field to ft2_source struct to track wide string length explicitly
• Pass the known buffer size (filesize) to os_utf8_to_wcs_ptr instead of strlen(), allowing embedded null bytes to be converted as regular characters
• Replace all wcslen(srcdata->text) calls with srcdata->text_len throughout the plugin
• Updated remove_cr(), cache_glyphs(), and get_ft2_text_width() to work with explicit lengths
• No changes needed to libobs/util/utf8.c — the existing utf8_to_wchar already handles embedded nulls correctly when insize is provided

This is safe because null bytes never appear as continuation bytes in valid UTF-8 sequences, and utf8_to_wchar documents that "If UTF-8 string contains zero symbols, they will be translated as regular symbols" when explicit size is given.

Testing

• Files with embedded null bytes between lines display completely
• Standard multi-line UTF-8 files show no regression
• Chat log mode (read_from_end path) tested with both null-byte and clean files
• Empty files handled without crashes

Resolves #7595

Checklist

• I have updated the code with clang-format
• I have reviewed the contributing guidelines
• I have tested the code
• All commit messages are properly formatted and commits are squashed where appropriate

[Fenrirthviti]

This appears to be a similar change to #11045

What makes this change more (or less) correct? The previous PR had discussion and landed in a method we were happy with, but fell through the cracks due to low priority.

EDIT: Fixed the link, copy/paste failed me :)

[4RH1T3CT0R7]

Thanks for pointing out #11045 - I wasn't aware of it when I submitted this PR.

After reviewing that PR and the prior discussion (#7628, #7595), I agree that explicitly tracking string lengths (as #11045 does) is the better approach - it preserves null bytes as characters rather than silently removing them, which aligns with the maintainers' preference for representing them as invalid character glyphs.

My initial approach (stripping null bytes) was essentially the same as what was rejected in #7628.

I've reworked this PR to follow the explicit length-tracking approach from #11045, rebased on the current master. Key changes:

• Added text_len field to ft2_source struct to track string length explicitly
• Pass the known buffer size to os_utf8_to_wcs instead of strlen(), so embedded null bytes are converted as regular characters
• Replace all wcslen(srcdata->text) calls with srcdata->text_len
• Updated remove_cr, cache_glyphs, and get_ft2_text_width to work with explicit lengths
• No changes needed to libobs/util/utf8.c - the existing utf8_to_wchar already handles embedded nulls correctly when insize is provided explicitly

Since #11045 has been open since July 2024, hopefully this helps move the fix forward.

@Fenrirthviti

[Fenrirthviti]

Thanks for the follow up. The PR being old doesn't mean we're not still considering it, or that is not still correct.

@kkartaltepe Does this now supersede your PR? I'd like to close one of these that are going towards the same goal, so we can focus review efforts on either one (which are scheduled for review next major version).

[Warchamp7]

Triage note: Need to determine if this or #11045 is better.