[IMPROVEMENT] Standardize number_bytes upper bound in ts_tables_epg.c#2253
[IMPROVEMENT] Standardize number_bytes upper bound in ts_tables_epg.c#2253THE-Amrit-mahto-05 wants to merge 2 commits intoCCExtractor:masterfrom
Conversation
CCExtractor CI platform finished running the test files on linux. Below is a summary of the test results, when compared to test for commit d56a6be...:
Your PR breaks these cases:
NOTE: The following tests have been failing on the master branch as well as the PR:
Congratulations: Merging this PR would fix the following tests:
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 CI platform finished running the test files on windows. Below is a summary of the test results, when compared to test for commit d56a6be...:
Your PR breaks these cases:
NOTE: The following tests have been failing on the master branch as well as the PR:
Congratulations: Merging this PR would fix the following tests:
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. |
|
Closing — there's no explanation for why the upper bound should change from 500 to 200. What problem does this solve? What sample triggers an issue with the current 500 limit? Without a repro or justification, we can't merge an arbitrary constant change. |
In raising this pull request, I confirm the following (please check boxes):
Reason for this PR:
Sanity check:
Reason
In
ts_tables_epg.c, the variablenumber_byteshad inconsistent upper bounds:This inconsistency can lead to unsafe memory handling and unpredictable parsing behavior.
Change
Standardized the upper bound to 200 to match existing validation logic.
Repro instructions
This change improves consistency and safety in bounds checking.
No specific crash case was reproduced, but inconsistent limits were observed in code.
why 200
The value 200 is already used in another validation block in the same file
(compression_type/mode check), so this change ensures consistency and avoids arbitrary limits.
Proof of warning when it was 500:


after chaning to 200:
