fix: add NULL checks to Rust FFI exports

[THE-Amrit-mahto-05]

In raising this pull request, I confirm the following (please check boxes):

• I have read and understood the contributors guide.
• I have checked that another pull request for this purpose does not exist.
• I have considered, and confirmed that this submission will be valuable to others.
• I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
• I give this submission freely, and claim no ownership to its content.
• I have mentioned this change in the changelog.

My familiarity with the project is as follows (check one):

• I have never used CCExtractor.
• I have used CCExtractor just a couple of times.
• I absolutely love CCExtractor, but have not contributed previously.
• I am an active contributor to CCExtractor.

---

Description

While reviewing the Rust FFI layer, I noticed several exported functions that
dereference raw pointers coming from C without checking for NULL.
If these functions are ever called with invalid inputs, this can lead to
undefined behavior.

I’m still learning Rust FFI, so please correct me if I’m misunderstanding
anything, but based on my understanding these look like genuine safety issues.

What this PR changes

• Adds defensive NULL checks to Rust FFI exports in:
  • libccxr_exports/mod.rs
  • libccxr_exports/bitstream.rs
• Adds a negative-length check to ccxr_verify_crc32
• Ensures FFI functions return safe defaults (0 or NULL) instead of causing UB
• Adds tests to verify safe behavior when called with NULL pointers

Testing

• Ran cargo test in src/rust
• All existing and newly added tests are passing

fixed #1983

[ccextractor-bot]

CCExtractor CI platform finished running the test files on linux. Below is a summary of the test results, when compared to test for commit 477307e...:

Report Name	Tests Passed
Broken	13/13
CEA-708	14/14
DVB	6/7
DVD	3/3
DVR-MS	2/2
General	27/27
Hardsubx	1/1
Hauppage	3/3
MP4	3/3
NoCC	10/10
Options	86/86
Teletext	20/21
WTV	13/13
XDS	34/34

Your PR breaks these cases:

• ccextractor --autoprogram --out=srt --latin1 --tpage 299 b8c55aa2e9...

NOTE: The following tests have been failing on the master branch as well as the PR:

• ccextractor --autoprogram --out=srt --latin1 --quant 0 85271be4d2..., Last passed:

  Test 7658

It seems that not all tests were passed completely. This is an indication that the output of some files is not as expected (but might be according to you).

Check the result page for more info.

[ccextractor-bot]

CCExtractor CI platform finished running the test files on windows. Below is a summary of the test results, when compared to test for commit 477307e...:

Report Name	Tests Passed
Broken	13/13
CEA-708	14/14
DVB	7/7
DVD	3/3
DVR-MS	2/2
General	27/27
Hardsubx	1/1
Hauppage	3/3
MP4	3/3
NoCC	10/10
Options	86/86
Teletext	20/21
WTV	13/13
XDS	34/34

Your PR breaks these cases:

• ccextractor --autoprogram --out=srt --latin1 --tpage 299 b8c55aa2e9...

It seems that not all tests were passed completely. This is an indication that the output of some files is not as expected (but might be according to you).

Check the result page for more info.

[cfsmp3]

I don't think this is needed.

• 1. If you don't have a bitstream that functions won't be called, the whole thing will fall apart way before getting there.
• 2. Because the unsafely derives from C and the C code is going away, all this FFI stuff is going to be removed anyway.

Also, we can't really have safeguards at the entry point of every function. There's invariants that are guaranteed by the logic (and verified with unit tests), so checking everything everywhere just adds a lot of bloat but doesn't really improve anything.