CCExtractor version: master (0.96)

Necessary information

• Is this a regression (i.e. did it work before)? NO (as far as I can tell this has been present in add_cc_sub_text for a while)
• What platform did you use? Windows (the bug is in portable C, not Windows-specific)
• What were the used arguments? Not a single-file extraction failure. This is a C string bug in a helper used by ISDB and HardSubx when those subtitles are later treated as C strings (for example transcript output with --transcript / showMode).

Video links

No sample file: the defect is visible from the source. Callers pass 4-character string literals into a strncpy of length 4, which does not write a terminator. I can add a sample later if maintainers want one for ISDB/HardSubx transcript output.

Additional information

Problem

add_cc_sub_text() in src/lib_ccx/ccx_common_common.c copies info and mode with strncpy(..., 4).

struct cc_subtitle stores:

• char mode[5] — 4 characters plus a required '\0'
• char info[4] — 3 characters plus a required '\0'

strncpy(dest, src, n) does not add a terminating '\0' when src is n characters long. It only pads with zeros when src is shorter than n.

Why this matters

Later code treats sub->mode as a C string:

• strcmp(sub->mode, "TLT") in src/lib_ccx/ccx_encoders_transcript.c
• fdprintf(..., "%s|", sub->mode) in the same file

If there is no terminator, strcmp / "%s" read past the array (undefined behavior: garbage in transcript output, or a crash).

Call sites that pass a 4-character mode

These are exactly 4 characters, so strncpy(..., 4) copies all four letters and never writes '\0':

• "ISDB" from src/lib_ccx/ccx_decoders_isdb.c
• "BURN" from src/lib_ccx/hardsubx_decoder.c

"TLT" is only 3 characters, so that path is terminated by strncpy itself.

mode[4] can still look correct on the first subtitle if the struct was created with calloc (zeros). The second node is allocated with malloc (not zeroed), so mode[4] is leftover garbage. That makes the bug easy to miss on a short run.

Proposed direction (not implemented in this issue)

Copy with sizeof(field) - 1 and always write the last byte as '\0', so mode and info are always valid C strings.

I would like to send a small PR for this if the diagnosis looks right.