[pranayr710]

Reason for this PR:

• This PR fixes a bug — undefined behaviour in the MKV parser, confirmed with UBSan on a generated corpus.

Sanity check:

• I have read and understood the contributors guide.
• I have checked that another pull request for this purpose does not exist.
• Bug fix, so NOT added to the changelog.
• Not adding new C code — one type change, eight places.

---

What was wrong

Every EBML parse loop in matroska.c accumulates the element ID a byte at a time into a signed int:

int code = 0, code_len = 0;
while (pos + len > get_current_byte(file))
{
        code <<= 8;
        code += mkv_read_byte(file);

On a well-formed file the switch matches within four bytes and code is reset. Nothing resets it when no case matches, so on malformed or truncated input the shift walks past INT_MAX — signed overflow, which is undefined behaviour (C11 6.5.7p4).

UBSan reports it at four of the eight identical loops:

../src/lib_ccx/matroska.c:489:8: runtime error: left shift of 8521680 by 8 places
                                 cannot be represented in type 'int'
../src/lib_ccx/matroska.c:1229, :1275, :1963  — same

The change

code becomes unsigned int in all eight loops. EBML IDs are at most four bytes, every case label is a positive constant, and the existing diagnostics already print it with mprint("... 0x%x ...", code), which expects unsigned — so this also fixes a latent format mismatch. Unsigned wraparound is well defined.

code_len is left as int; it is only a counter.

Reproducing

# any MKV with a subtitle track; mutate some SimpleBlock size bytes
ffmpeg -f lavfi -i "testsrc=size=160x120:rate=10:duration=8" -i subs.srt \
       -map 0:v -map 1:s -c:v libx264 -c:s srt base.mkv
# then build with -fsanitize=undefined and run
ccextractor fuzzed.mkv --out=srt -o out.srt

One gotcha that cost me time: CCExtractor writes each MKV subtitle track to a file next to the input, so with a read-only input directory it stops at Error: Cannot create output file for subtitle track before reaching the parser loops. The input directory has to be writable to reach this code.

Verification

Built master and this branch from identical source in the same image.

	master	this PR
UBSan over a 25-file fuzzed MKV corpus	3 sites	0
Well-formed MKV extracted track	a58ba9a536	a58ba9a536 (stable over 5 runs each)
Compiler warnings	15	15 (all pre-existing)

One thing to be straight about: three truncated inputs show differing stdout between the two builds — but master already differs from itself on those. Its "Unknown element 0x%x" diagnostic prints the accumulator, whose value was undefined precisely because of this bug. Running master alone five times produces the same set of hashes that the comparison flagged:

t25  master:{adc1cc3a, e982434a}   this PR:{adc1cc3a, e982434a}
t50  master:{0812afe2, cc9a3f71}   this PR:{0812afe2, cc9a3f71}

So that is pre-existing nondeterminism on malformed input, not a change in behaviour. Well-formed files are byte-identical.

This is UB a compiler is entitled to exploit rather than an observed misbehaviour — on x86/GCC today the shift does what you would naively expect. Same category as #2353.