[BUG FIX] Add NULL check for fopen return value in process_hex()

[Anayo-Anyafulu]

Summary

In process_hex() in src/lib_ccx/general_loop.c, fopen() was called without checking if the returned FILE pointer is NULL. If the file cannot be opened, the subsequent fgets() call would crash with a NULL pointer dereference.

Changes

• src/lib_ccx/general_loop.c — added NULL check after fopen(), prints an error message and returns early if the file cannot be opened.

Testing

Manually verified the fix compiles cleanly.

[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 c3c5d9c...:

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

Your PR breaks these cases:

• ccextractor --autoprogram --out=srt --latin1 --quant 0 85271be4d2...
• ccextractor --autoprogram --out=ttxt --latin1 --ucla dab1c1bd65...
• ccextractor --out=srt --latin1 --autoprogram 29e5ffd34b...
• ccextractor --out=spupng c83f765c66...
• ccextractor --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
• ccextractor --startcreditsnotbefore 1 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
• ccextractor --startcreditsnotafter 2 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
• ccextractor --startcreditsforatleast 1 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...
• ccextractor --startcreditsforatmost 2 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9...

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 8de778a...:

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	21/21
WTV	13/13
XDS	34/34

Congratulations: Merging this PR would fix the following tests:

• ccextractor --autoprogram --out=srt --latin1 --quant 0 85271be4d2..., Last passed: Never
• ccextractor --autoprogram --out=ttxt --latin1 --ucla dab1c1bd65..., Last passed: Never
• ccextractor --out=srt --latin1 --autoprogram 29e5ffd34b..., Last passed: Never
• ccextractor --out=spupng c83f765c66..., Last passed: Never
• ccextractor --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed: Never
• ccextractor --startcreditsnotbefore 1 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed: Never
• ccextractor --startcreditsnotafter 2 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed: Never
• ccextractor --startcreditsforatleast 1 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed: Never
• ccextractor --startcreditsforatmost 2 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed: Never

All tests passed completely.

Check the result page for more info.

[cfsmp3]

The NULL check is needed, but the error handling should use fatal() instead of mprint() + return.

Right now, if the file can't be opened, process_hex silently returns and the program exits with success (code 0). The caller in ccextractor.c:253 is a switch case that just breaks after the call — so scripts and users will think processing succeeded when it actually did nothing.

The existing pattern in this same function uses fatal() for the malloc failure on line 367. This should be consistent:

if (!fr)
{
    fatal(EXIT_READ_ERROR, "Error: Could not open hex file %s\n", filename);
}

(No need to free(line) if you use fatal() since it terminates the process.)