While this might not be necessary technically, cppcheck complained: overviewscintilla.c:800:53: note: Calling function 'overview_scintilla_get_overlay_color', 2nd argument '&color' value is <Uninit> overview_scintilla_get_overlay_color (self, &color); ^ overviewscintilla.c:1146:11: note: Uninitialized variable: color You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany-plugins/pull/916
-- Commit Summary --
* Overview: initialize color variables
-- File Changes --
M overview/overview/overviewscintilla.c (4)
-- Patch Links --
https://github.com/geany/geany-plugins/pull/916.patch https://github.com/geany/geany-plugins/pull/916.diff
Newer cppcheck versions (probably 1.89 which is in Debian Sid since a few days) complained about it and so the nightly builds broke.
Maybe it's a bug in cppcheck?
But or not I think setting a variable to a default is a good thing.
It would appear to be a correct warning, there is nothing to tell cppcheck that argument 2 is an out only argument so it has to assume the value is used in the function and hence an uninitialised value is being passed.
But or not I think setting a variable to a default is a good thing.
I haven't done a proper survey, but I'd wager if we did, we'd find hundreds if not thousands of uninitialized variables in Geany and GP's code.
there is nothing to tell cppcheck that argument 2 is an out
If it did proper analysis (ie. look into callee) it would see it's passed to `memcpy` and fully written.
In any case, I'm fine with this PR if it shuts up `cppcheck`; this isn't performance critical in anyway, and it doesn't affect readability.
codebrainz approved this pull request.
If it did proper analysis (ie. look into callee) it would see it's passed to memcpy and fully written.
1. "if" :)
2. and if it, did the return_ifs can shortcut return and leave it uninitialised.
I don't mind much. If you think it's a false-positive in `cppcheck`, then you should report it (or comment on https://trac.cppcheck.net/ticket/9347, it looks close to our case).
In any case, I'm fine with this PR if it shuts up cppcheck; this isn't performance critical in anyway, and it doesn't affect readability.
I agree to this and vote for merging it.
It looks like maybe it was fixed in danmar/cppcheck#2167, but I haven't tested it.
- and if it did, the return_ifs can shortcut return and leave it uninitialised.
@elextr got a point, it's actually technically correct to say the value may not be initialized because of those checks, and it seem impossible for a tool to infer that those checks will succeed, even if we know they will -- unless something else went terribly bad and we're fubar.
So although I initially blamed that on cppcheck, I guess it's fair and this PR makes sense.
it's actually technically correct to say the value may not be initialized because of those checks
Depending on whether they're actually enabled, of course.
Merged #916 into master.
github-comments@lists.geany.org