Skip to content

Comments

Added defensiveness running out of bits during parse#8

Merged
theRealRobG merged 2 commits intomainfrom
bug/defensiveness-against-unexpected-end-of-bits
Jun 16, 2025
Merged

Added defensiveness running out of bits during parse#8
theRealRobG merged 2 commits intomainfrom
bug/defensiveness-against-unexpected-end-of-bits

Conversation

@theRealRobG
Copy link
Owner

Within MsbBitReader, all calls to consuming bits come with a precondition check, which causes a crash if it fails. We did have some validation within the project for making sure enough bits were left before some calls; however, it was only in select places. This change makes all calls to DataReader throwing, with a check on whether enough bits are left before allowing them to be read. This may be a dent on performance; however, it is probably worth the extra protection against application crashes.

This change is added because we found crashes in the wild due to badly formatted SCTE35 messages. These should be corrected; however, the parser should also be more defensive.

Within MsbBitReader, all calls to consuming bits come with a
precondition check, which causes a crash if it fails. We did have some
validation within the project for making sure enough bits were left
before some calls; however, it was only in select places. This change
makes all calls to DataReader throwing, with a check on whether enough
bits are left before allowing them to be read. This may be a dent on
performance; however, it is probably worth the extra protection against
application crashes.

This change is added because we found crashes in the wild due to badly
formatted SCTE35 messages. These should be corrected; however, the
parser should also be more defensive.
@theRealRobG theRealRobG self-assigned this Jun 15, 2025
@theRealRobG theRealRobG added the enhancement New feature or request label Jun 15, 2025
@theRealRobG
Copy link
Owner Author

From the test output I can see the following:
/__w/SCTE35Parser/SCTE35Parser/Tests/SCTE35ParserTests/SCTE35ParserMeasurements.swift:43: Test Case 'SCTE35ParserMeasurements.test_performance_of_many_scte35_messages' measured [Time, seconds] average: 0.005, relative standard deviation: 5.578%, values: [0.005775, 0.005625, 0.005185, 0.005238, 0.005200, 0.005216, 0.005306, 0.005277, 0.005570, 0.006080], performanceMetricID:org.swift.XCTPerformanceMetric_WallClockTime, maxPercentRelativeStandardDeviation: 10.000%, maxStandardDeviation: 0.100

Comparing against the build that introduced metrics into main branch, I see:
/__w/SCTE35Parser/SCTE35Parser/Tests/SCTE35ParserTests/SCTE35ParserMeasurements.swift:43: Test Case 'SCTE35ParserMeasurements.test_performance_of_many_scte35_messages' measured [Time, seconds] average: 0.006, relative standard deviation: 2.456%, values: [0.005982, 0.005551, 0.005536, 0.005575, 0.005534, 0.005548, 0.005564, 0.005572, 0.005511, 0.005584], performanceMetricID:org.swift.XCTPerformanceMetric_WallClockTime, maxPercentRelativeStandardDeviation: 10.000%, maxStandardDeviation: 0.100

So the performance seems no worse.

@theRealRobG theRealRobG merged commit 9475cbe into main Jun 16, 2025
1 check passed
@theRealRobG theRealRobG deleted the bug/defensiveness-against-unexpected-end-of-bits branch June 16, 2025 02:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant