Hi,
Lukas Javorsky wrote:
> From my analysis, I believe that if the `GCC_LINT` or `lint` macros
> are not defined, the elements `i`, `j`, and `count` from the
> `gl_map_iterator_t` struct are not initialized
Correct.
They are not initialized because they are not used. Look at the
gl_tree_iterator_next and gl_tree_iterator_free functions in the same file.
> > I'm analyzing the results of SAST reports (combination of
> coverity,snyk,cppcheck,gcc,clang,shellcheck,unicontrol)
And you got no report from valgrind. Because valgrind, being a dynamic tool,
does a better job at avoiding false positives than the static analysis tools.
> (which could cause an undefined behavior).
No, it can't. Copying and then discarding an uninitialized value of integer
or pointer type (i.e. not a signalling NaN (*)) is not undefined behaviour.
> and from 20
> findings I identified a few that might be a true positive.
The fact that it's marked with
#if defined GCC_LINT || defined lint
should have made it clear to you that we, the upstream developers, know
about this false positive.
Bruno
(*) Maybe the same holds for signalling NaNs as well. I don't know. It's
irrelevant here.
