safety: refactor iffoutput.cpp for memory safety #4144
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Static analysis has been yelling about code in iffoutput.cpp possibly overrunning buffers, and frankly the code in this module is so confusing that I can't tell if it's correct or not. (It's 13 years old, hasn't been touched for a long time.) In an ideal world, this would all be rewritten to use spans so the buffer lengths are known and checked. But I don't really have the time or inclination to rewrite it -- after all, iff is not a very important file format, though I do think it's used enough that we can't drop it entirely. The payoff from a full rewrite is marginal. So I came up with the following compromise, embied by this PR: I'm making spans of the regions we're ultimately reading from and writing to, passing those down the chain of function calls, and so even though the actual operations are total pointer arithmetic spaghetti, we can use those spans to verify that the pointers are still within the span bounds any time we read or write through them. We do it with assertions that are only active for debug builds, so there shouldn't be any measurable performance hit. But the assertions will be active in CI for both the static and dynamic analysis tests, so should catch any latent bugs. Signed-off-by: Larry Gritz <lg@larrygritz.com>
|
no objections -> merging |
lgritz
merged commit b8bb38e
into
AcademySoftwareFoundation:master
24 of 25 checks passed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Static analysis has been yelling about code in iffoutput.cpp possibly overrunning buffers, and frankly the code in this module is so confusing that I can't tell if it's correct or not. (It's 13 years old, hasn't been touched for a long time.)
In an ideal world, this would all be rewritten to use spans so the buffer lengths are known and checked. But I don't really have the time or inclination to rewrite it -- after all, iff is not a very important file format, though I do think it's used enough that we can't drop it entirely. The payoff from a full rewrite is marginal. So I came up with the following compromise, embodied by this PR:
I'm making spans of the regions we're ultimately reading from and writing to, passing those down the chain of function calls, and so even though the actual operations are total pointer arithmetic spaghetti, we can use those spans to verify that the pointers are still within the span bounds any time we read or write through them. We do it with assertions that are only active for debug builds, so there shouldn't be any measurable performance hit. But the assertions will be active in CI for both the static and dynamic analysis tests, so should catch any latent bugs.