-
Enhancement
-
Resolution: Fixed
-
P4
-
11, 16, 17
-
b16
SonarCloud instance reports the bug in cases like:
"Address of stack memory associated with local variable 'callback' is still referred to by the global variable '_subsystem_callback' upon returning to the caller. This will be a dangling reference"
static void clear_packages() {
ClearArtifact<PkgPtr> clear;
ClearPackageCallback callback(&clear);
_subsystem_callback = &callback;
do_packages();
}
I understand that _subsystem_callback is assigned to be used in do_packages(), but it would indeed be left dangling. Maybe we should be doing something like CallbackInstallMark that would set _subsystem_callback back to NULL after we are done? Or, make Callbacks (i.e. ClearPackageCallback) self-installable, so they would both set themselves to _subsystem_callback and remove themselves?
"Address of stack memory associated with local variable 'callback' is still referred to by the global variable '_subsystem_callback' upon returning to the caller. This will be a dangling reference"
static void clear_packages() {
ClearArtifact<PkgPtr> clear;
ClearPackageCallback callback(&clear);
_subsystem_callback = &callback;
do_packages();
}
I understand that _subsystem_callback is assigned to be used in do_packages(), but it would indeed be left dangling. Maybe we should be doing something like CallbackInstallMark that would set _subsystem_callback back to NULL after we are done? Or, make Callbacks (i.e. ClearPackageCallback) self-installable, so they would both set themselves to _subsystem_callback and remove themselves?