You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
refactor: Use spans to solve a number of memory safety issues (#4148)
* exif.cpp: use spans to avoid several possible buffer overruns
* paramlist_test.cpp: use spans to be sure we're ok on memory bounds
* jpeg: use spans in jpeg icc profile manipulation for memory safety
* psd output: switch cmyk conversion to use spans for memory safety
I've been cobbling these together bit by bit over the last several
weeks, tracking down the memory safety issues identified by the Sonar
static analysis. I think that *mostly* they are not real bugs, but the
code is confusing enough that it's hard to verify. This refactor makes
it safer, and even if the code was previously correct but merely hard to
analyze, the bounds checking in span (for debug mode) gives the static
analyzer the clues it needs to know this is safe.
As further explanation, these situations generally involve something
that looks like this, schematically:
caller () {
T buffer[known_size];
call function(buffer, ...params...);
}
function(T* buffer, ...params...) {
i, j = ...very complex things, hard to analyze...
foo = buffer[i];
buffer[j] = bar;
// Did we do a buffer overrun??? ¯\_(ツ)_/¯
// This function doesn't necessarily have knowldege of the
// true bounds, even if it wanted to check every access.
}
By rewriting this function as follows:
function(span<T> buffer) {
// all indexed access to buffer will be bounds checked in debug
}
we are passing the bounds as well, and at least for debug builds, are
also checking bounds with an assertion on every indexed access into
buffer, without the function needing a lot of clutter. Fire and forget.
---------
Signed-off-by: Larry Gritz <[email protected]>
0 commit comments