[PATCH 0/6] fix uninitialized variable warning

[PATCH 0/6] fix uninitialized variable warning

[Chen Qun]

Hi all,
  There are some variables initialized warnings reported by the compiler,
even if the default CFLAG for the compiler parameters are uesed.

This serial has added some default values or changed the assignment places for the variablies to fix them.

Thanks,
Chen Qun


Chen Qun (6):
  target/xtensa: fix uninitialized variable warning
  hw/rdma/rdma_backend: fix uninitialized variable warning in
    rdma_poll_cq()
  util/qemu-timer: fix uninitialized variable warning in
    timer_mod_anticipate_ns()
  util/qemu-timer: fix uninitialized variable warning for expire_time
  plugins/loader: fix uninitialized variable warning in
    plugin_reset_uninstall()
  migration: fix uninitialized variable warning in
    migrate_send_rp_req_pages()

 hw/rdma/rdma_backend.c    | 2 +-
 migration/migration.c     | 2 +-
 plugins/loader.c          | 2 +-
 target/xtensa/translate.c | 2 +-
 util/qemu-timer.c         | 8 +++-----
 5 files changed, 7 insertions(+), 9 deletions(-)

-- 
2.27.0

[PATCH 1/6] target/xtensa: fix uninitialized variable warning

[Chen Qun]

The compiler cannot determine whether the return values of the xtensa_operand_is_register(isa, opc, opnd)
 and xtensa_operand_is_visible(isa, opc, opnd) functions are the same.
So,it assumes that 'rf' is not assigned, but it's used.

The compiler showed warning:
target/xtensa/translate.c: In function ‘disas_xtensa_insn’:
target/xtensa/translate.c:985:43: warning: ‘rf’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  985 |                     arg[vopnd].num_bits = xtensa_regfile_num_bits(isa, rf);
      |                                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Add a default value for 'rf' to prevented the warning.

Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
---
Cc: Max Filippov <jcmvbkbc@gmail.com>
---
 target/xtensa/translate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/xtensa/translate.c b/target/xtensa/translate.c
index 944a157747..eea851bbe7 100644
--- a/target/xtensa/translate.c
+++ b/target/xtensa/translate.c
@@ -953,7 +953,7 @@ static void disas_xtensa_insn(CPUXtensaState *env, DisasContext *dc)
 
         for (opnd = vopnd = 0; opnd < opnds; ++opnd) {
             void **register_file = NULL;
-            xtensa_regfile rf;
+            xtensa_regfile rf = -1;
 
             if (xtensa_operand_is_register(isa, opc, opnd)) {
                 rf = xtensa_operand_regfile(isa, opc, opnd);
-- 
2.27.0

Re: [PATCH 1/6] target/xtensa: fix uninitialized variable warning

[Philippe Mathieu-Daudé]

On 11/3/20 2:52 AM, Chen Qun wrote:
> The compiler cannot determine whether the return values of the xtensa_operand_is_register(isa, opc, opnd)
>  and xtensa_operand_is_visible(isa, opc, opnd) functions are the same.
> So,it assumes that 'rf' is not assigned, but it's used.
> 
> The compiler showed warning:
> target/xtensa/translate.c: In function ‘disas_xtensa_insn’:
> target/xtensa/translate.c:985:43: warning: ‘rf’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>   985 |                     arg[vopnd].num_bits = xtensa_regfile_num_bits(isa, rf);
>       |                                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Add a default value for 'rf' to prevented the warning.
> 
> Reported-by: Euler Robot <euler.robot@huawei.com>
> Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
> ---
> Cc: Max Filippov <jcmvbkbc@gmail.com>
> ---
>  target/xtensa/translate.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/xtensa/translate.c b/target/xtensa/translate.c
> index 944a157747..eea851bbe7 100644
> --- a/target/xtensa/translate.c
> +++ b/target/xtensa/translate.c
> @@ -953,7 +953,7 @@ static void disas_xtensa_insn(CPUXtensaState *env, DisasContext *dc)
>  
>          for (opnd = vopnd = 0; opnd < opnds; ++opnd) {
>              void **register_file = NULL;
> -            xtensa_regfile rf;
> +            xtensa_regfile rf = -1;

NAck (code smells).

Deferring to Max, but possible fix:

-- >8 --
@@ -953,10 +953,9 @@ static void disas_xtensa_insn(CPUXtensaState *env,
DisasContext *dc)

         for (opnd = vopnd = 0; opnd < opnds; ++opnd) {
             void **register_file = NULL;
-            xtensa_regfile rf;
+            xtensa_regfile rf = xtensa_operand_regfile(isa, opc, opnd);

             if (xtensa_operand_is_register(isa, opc, opnd)) {
-                rf = xtensa_operand_regfile(isa, opc, opnd);
                 register_file = dc->config->regfile[rf];

                 if (rf == dc->config->a_regfile) {
---

Re: [PATCH 1/6] target/xtensa: fix uninitialized variable warning

[Max Filippov]

On Mon, Nov 2, 2020 at 5:52 PM Chen Qun <kuhn.chenqun@huawei.com> wrote:
>
> The compiler cannot determine whether the return values of the xtensa_operand_is_register(isa, opc, opnd)
>  and xtensa_operand_is_visible(isa, opc, opnd) functions are the same.

It doesn't have to because 1) they definitely are not the same, but
2) it doesn't matter.

> So,it assumes that 'rf' is not assigned, but it's used.

The assumption is wrong. rf is used under the 'if (register_file)'
condition and register_file is initialized to NULL and then set
to something non-NULL based on the value of rf here:

958             if (xtensa_operand_is_register(isa, opc, opnd)) {
959                 rf = xtensa_operand_regfile(isa, opc, opnd);
960                 register_file = dc->config->regfile[rf];

> The compiler showed warning:
> target/xtensa/translate.c: In function ‘disas_xtensa_insn’:
> target/xtensa/translate.c:985:43: warning: ‘rf’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>   985 |                     arg[vopnd].num_bits = xtensa_regfile_num_bits(isa, rf);
>       |                                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Add a default value for 'rf' to prevented the warning.

I don't see it doing default build with gcc 8.3. But then I don't see
-Wmaybe-uninitialized in the compiler command line either.

> Reported-by: Euler Robot <euler.robot@huawei.com>
> Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
> ---
> Cc: Max Filippov <jcmvbkbc@gmail.com>
> ---
>  target/xtensa/translate.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/xtensa/translate.c b/target/xtensa/translate.c
> index 944a157747..eea851bbe7 100644
> --- a/target/xtensa/translate.c
> +++ b/target/xtensa/translate.c
> @@ -953,7 +953,7 @@ static void disas_xtensa_insn(CPUXtensaState *env, DisasContext *dc)
>
>          for (opnd = vopnd = 0; opnd < opnds; ++opnd) {
>              void **register_file = NULL;
> -            xtensa_regfile rf;
> +            xtensa_regfile rf = -1;

Please use XTENSA_UNDEFINED instead if you still think this
is worth changing.

-- 
Thanks.
-- Max

RE: [PATCH 1/6] target/xtensa: fix uninitialized variable warning

[Chenqun (kuhn)]

> -----Original Message-----
> From: Max Filippov [mailto:jcmvbkbc@gmail.com]
> Sent: Tuesday, November 3, 2020 5:22 PM
> To: Chenqun (kuhn) <kuhn.chenqun@huawei.com>
> Cc: qemu-devel <qemu-devel@nongnu.org>; QEMU Trivial
> <qemu-trivial@nongnu.org>; Zhanghailiang
> <zhang.zhanghailiang@huawei.com>; ganqixin <ganqixin@huawei.com>; Euler
> Robot <euler.robot@huawei.com>
> Subject: Re: [PATCH 1/6] target/xtensa: fix uninitialized variable warning
> 
> On Mon, Nov 2, 2020 at 5:52 PM Chen Qun <kuhn.chenqun@huawei.com>
> wrote:
> >
> > The compiler cannot determine whether the return values of the
> > xtensa_operand_is_register(isa, opc, opnd)  and
> xtensa_operand_is_visible(isa, opc, opnd) functions are the same.
> 
> It doesn't have to because 1) they definitely are not the same, but
> 2) it doesn't matter.
> 
> > So,it assumes that 'rf' is not assigned, but it's used.
> 
> The assumption is wrong. rf is used under the 'if (register_file)'
> condition and register_file is initialized to NULL and then set to something
> non-NULL based on the value of rf here:
> 
Hi Max,
  Yeah, your analysis is correct. This rf is used only when register_file is non-NULL. When this condition is met, the rf must have been assigned a value.
The GCC 9.3 compilation I use contains the Wmaybe-uninitialized parameter by default. It cannot recognize this complex logic judgment.
This warning may be frequently encountered by developers who compile this part of code.

> 958             if (xtensa_operand_is_register(isa, opc, opnd)) {
> 959                 rf = xtensa_operand_regfile(isa, opc, opnd);
> 960                 register_file = dc->config->regfile[rf];
> 
> > The compiler showed warning:
> > target/xtensa/translate.c: In function ‘disas_xtensa_insn’:
> > target/xtensa/translate.c:985:43: warning: ‘rf’ may be used uninitialized in
> this function [-Wmaybe-uninitialized]
> >   985 |                     arg[vopnd].num_bits =
> xtensa_regfile_num_bits(isa, rf);
> >       |
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > Add a default value for 'rf' to prevented the warning.
> 
> I don't see it doing default build with gcc 8.3. But then I don't see
> -Wmaybe-uninitialized in the compiler command line either.
> 
Maybe it's available after GCC9, or some CFLAG configuration.

The -Wmaybe-uninitialized parameter has this description：
"These warnings are only possible in optimizing compilation, because otherwise GCC does not keep track of the state of variables."
From：https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options

I have tried to configure only "-O2 -fexceptions" for the CFLAG on GCC9, and this warning will occur.

> > Reported-by: Euler Robot <euler.robot@huawei.com>
> > Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
> > ---
> > Cc: Max Filippov <jcmvbkbc@gmail.com>
> > ---
> >  target/xtensa/translate.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/target/xtensa/translate.c b/target/xtensa/translate.c
> > index 944a157747..eea851bbe7 100644
> > --- a/target/xtensa/translate.c
> > +++ b/target/xtensa/translate.c
> > @@ -953,7 +953,7 @@ static void disas_xtensa_insn(CPUXtensaState *env,
> > DisasContext *dc)
> >
> >          for (opnd = vopnd = 0; opnd < opnds; ++opnd) {
> >              void **register_file = NULL;
> > -            xtensa_regfile rf;
> > +            xtensa_regfile rf = -1;
> 
> Please use XTENSA_UNDEFINED instead if you still think this is worth changing.
> 
I don't think it's wrong, it's just a bit of trouble for the compiler :)

Thanks,
Chen Qun

[PATCH 2/6] hw/rdma/rdma_backend: fix uninitialized variable warning in rdma_poll_cq()

[Chen Qun]

After the WITH_QEMU_LOCK_GUARD macro is added, the compiler cannot identify
 that the statements in the macro must be executed. As a result, some variables
 assignment statements in the macro may be considered as unexecuted by the compiler.

The compiler showed warning:
hw/rdma/rdma_backend.c: In function ‘rdma_poll_cq’:
hw/rdma/rdma_utils.h:25:5: warning: ‘ne’ may be used uninitialized in this function [-Wmaybe-uninitialized]
 25 |     error_report("%s: " fmt, "rdma", ## __VA_ARGS__)
    |     ^~~~~~~~~~~~
hw/rdma/rdma_backend.c:93:12: note: ‘ne’ was declared here
 93 |     int i, ne, total_ne = 0;
    |            ^~

Add a default value for 'ne' to prevented the warning.

Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
---
Cc: Yuval Shaia <yuval.shaia.ml@gmail.com>
Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
---
 hw/rdma/rdma_backend.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/rdma/rdma_backend.c b/hw/rdma/rdma_backend.c
index 5de010b1fa..2fe4a3501c 100644
--- a/hw/rdma/rdma_backend.c
+++ b/hw/rdma/rdma_backend.c
@@ -90,7 +90,7 @@ static void clean_recv_mads(RdmaBackendDev *backend_dev)
 
 static int rdma_poll_cq(RdmaDeviceResources *rdma_dev_res, struct ibv_cq *ibcq)
 {
-    int i, ne, total_ne = 0;
+    int i, ne = 0, total_ne = 0;
     BackendCtx *bctx;
     struct ibv_wc wc[2];
     RdmaProtectedGSList *cqe_ctx_list;
-- 
2.27.0

Re: [PATCH 2/6] hw/rdma/rdma_backend: fix uninitialized variable warning in rdma_poll_cq()

[Marcel Apfelbaum]

[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]

Hi Chen,

On Tue, Nov 3, 2020 at 3:53 AM Chen Qun <kuhn.chenqun@huawei.com> wrote:

> After the WITH_QEMU_LOCK_GUARD macro is added, the compiler cannot identify
>  that the statements in the macro must be executed. As a result, some
> variables
>  assignment statements in the macro may be considered as unexecuted by the
> compiler.
>
> The compiler showed warning:
> hw/rdma/rdma_backend.c: In function ‘rdma_poll_cq’:
> hw/rdma/rdma_utils.h:25:5: warning: ‘ne’ may be used uninitialized in this
> function [-Wmaybe-uninitialized]
>  25 |     error_report("%s: " fmt, "rdma", ## __VA_ARGS__)
>     |     ^~~~~~~~~~~~
> hw/rdma/rdma_backend.c:93:12: note: ‘ne’ was declared here
>  93 |     int i, ne, total_ne = 0;
>     |            ^~
>
> Add a default value for 'ne' to prevented the warning.
>
> Reported-by: Euler Robot <euler.robot@huawei.com>
> Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
> ---
> Cc: Yuval Shaia <yuval.shaia.ml@gmail.com>
> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
> ---
>  hw/rdma/rdma_backend.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/rdma/rdma_backend.c b/hw/rdma/rdma_backend.c
> index 5de010b1fa..2fe4a3501c 100644
> --- a/hw/rdma/rdma_backend.c
> +++ b/hw/rdma/rdma_backend.c
> @@ -90,7 +90,7 @@ static void clean_recv_mads(RdmaBackendDev *backend_dev)
>
>  static int rdma_poll_cq(RdmaDeviceResources *rdma_dev_res, struct ibv_cq
> *ibcq)
>  {
> -    int i, ne, total_ne = 0;
> +    int i, ne = 0, total_ne = 0;
>      BackendCtx *bctx;
>      struct ibv_wc wc[2];
>      RdmaProtectedGSList *cqe_ctx_list;
> --
> 2.27.0
>
>
Reviewed-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>

Thanks for the fix,
Marcel

[-- Attachment #2: Type: text/html, Size: 2622 bytes --]

Re: [PATCH 2/6] hw/rdma/rdma_backend: fix uninitialized variable warning in rdma_poll_cq()

[Yuval Shaia]

[-- Attachment #1: Type: text/plain, Size: 1725 bytes --]

Thanks,

Reviewed-by:  Yuval Shaia <yuval.shaia.ml@gmail.com>

On Tue, 3 Nov 2020 at 03:53, Chen Qun <kuhn.chenqun@huawei.com> wrote:

> After the WITH_QEMU_LOCK_GUARD macro is added, the compiler cannot identify
>  that the statements in the macro must be executed. As a result, some
> variables
>  assignment statements in the macro may be considered as unexecuted by the
> compiler.
>
> The compiler showed warning:
> hw/rdma/rdma_backend.c: In function ‘rdma_poll_cq’:
> hw/rdma/rdma_utils.h:25:5: warning: ‘ne’ may be used uninitialized in this
> function [-Wmaybe-uninitialized]
>  25 |     error_report("%s: " fmt, "rdma", ## __VA_ARGS__)
>     |     ^~~~~~~~~~~~
> hw/rdma/rdma_backend.c:93:12: note: ‘ne’ was declared here
>  93 |     int i, ne, total_ne = 0;
>     |            ^~
>
> Add a default value for 'ne' to prevented the warning.
>
> Reported-by: Euler Robot <euler.robot@huawei.com>
> Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
> ---
> Cc: Yuval Shaia <yuval.shaia.ml@gmail.com>
> Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
> ---
>  hw/rdma/rdma_backend.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/rdma/rdma_backend.c b/hw/rdma/rdma_backend.c
> index 5de010b1fa..2fe4a3501c 100644
> --- a/hw/rdma/rdma_backend.c
> +++ b/hw/rdma/rdma_backend.c
> @@ -90,7 +90,7 @@ static void clean_recv_mads(RdmaBackendDev *backend_dev)
>
>  static int rdma_poll_cq(RdmaDeviceResources *rdma_dev_res, struct ibv_cq
> *ibcq)
>  {
> -    int i, ne, total_ne = 0;
> +    int i, ne = 0, total_ne = 0;
>      BackendCtx *bctx;
>      struct ibv_wc wc[2];
>      RdmaProtectedGSList *cqe_ctx_list;
> --
> 2.27.0
>
>

[-- Attachment #2: Type: text/html, Size: 2494 bytes --]

[PATCH 3/6] util/qemu-timer: fix uninitialized variable warning in timer_mod_anticipate_ns()

[Chen Qun]

After the WITH_QEMU_LOCK_GUARD macro is added, the compiler cannot identify
 that the statements in the macro must be executed. As a result, some variables
 assignment statements in the macro may be considered as unexecuted by the compiler.

The compiler showed warning:
util/qemu-timer.c: In function ‘timer_mod_anticipate_ns’:
util/qemu-timer.c:474:8: warning: ‘rearm’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  474 |     if (rearm) {
      |        ^

Change the default value assignment place to prevented the warning.

Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
---
Cc: Paolo Bonzini <pbonzini@redhat.com>
---
 util/qemu-timer.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/util/qemu-timer.c b/util/qemu-timer.c
index 81c28af517..8b73882fbb 100644
--- a/util/qemu-timer.c
+++ b/util/qemu-timer.c
@@ -459,7 +459,7 @@ void timer_mod_ns(QEMUTimer *ts, int64_t expire_time)
 void timer_mod_anticipate_ns(QEMUTimer *ts, int64_t expire_time)
 {
     QEMUTimerList *timer_list = ts->timer_list;
-    bool rearm;
+    bool rearm = false;
 
     WITH_QEMU_LOCK_GUARD(&timer_list->active_timers_lock) {
         if (ts->expire_time == -1 || ts->expire_time > expire_time) {
@@ -467,8 +467,6 @@ void timer_mod_anticipate_ns(QEMUTimer *ts, int64_t expire_time)
                 timer_del_locked(timer_list, ts);
             }
             rearm = timer_mod_ns_locked(timer_list, ts, expire_time);
-        } else {
-            rearm = false;
         }
     }
     if (rearm) {
-- 
2.27.0

Re: [PATCH 3/6] util/qemu-timer: fix uninitialized variable warning in timer_mod_anticipate_ns()

[Philippe Mathieu-Daudé]

On 11/3/20 2:52 AM, Chen Qun wrote:
> After the WITH_QEMU_LOCK_GUARD macro is added, the compiler cannot identify
>  that the statements in the macro must be executed. As a result, some variables
>  assignment statements in the macro may be considered as unexecuted by the compiler.
> 
> The compiler showed warning:
> util/qemu-timer.c: In function ‘timer_mod_anticipate_ns’:
> util/qemu-timer.c:474:8: warning: ‘rearm’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>   474 |     if (rearm) {
>       |        ^
> 
> Change the default value assignment place to prevented the warning.
> 
> Reported-by: Euler Robot <euler.robot@huawei.com>
> Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
> ---
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  util/qemu-timer.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>

[PATCH 4/6] util/qemu-timer: fix uninitialized variable warning for expire_time

[Chen Qun]

After the WITH_QEMU_LOCK_GUARD macro is added, the compiler cannot identify
 that the statements in the macro must be executed. As a result, some variables
 assignment statements in the macro may be considered as unexecuted by the compiler.

The compiler showed warning:
util/qemu-timer.c: In function ‘timerlist_expired’:
util/qemu-timer.c:199:24: warning: ‘expire_time’ may be used uninitialized in this function [-Wmaybe-uninitialized]
 199 |     return expire_time <= qemu_clock_get_ns(timer_list->clock->type);
     |            ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
util/qemu-timer.c: In function ‘timerlist_deadline_ns’:
util/qemu-timer.c:237:11: warning: ‘expire_time’ may be used uninitialized in this function [-Wmaybe-uninitialized]
 237 |     delta = expire_time - qemu_clock_get_ns(timer_list->clock->type);
     |     ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Add a default value for 'expire_time' to prevented the warning.

Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
---
Cc: Paolo Bonzini <pbonzini@redhat.com>
---
 util/qemu-timer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/util/qemu-timer.c b/util/qemu-timer.c
index 8b73882fbb..3910003e86 100644
--- a/util/qemu-timer.c
+++ b/util/qemu-timer.c
@@ -183,7 +183,7 @@ bool qemu_clock_has_timers(QEMUClockType type)
 
 bool timerlist_expired(QEMUTimerList *timer_list)
 {
-    int64_t expire_time;
+    int64_t expire_time = -1;
 
     if (!qatomic_read(&timer_list->active_timers)) {
         return false;
@@ -213,7 +213,7 @@ bool qemu_clock_expired(QEMUClockType type)
 int64_t timerlist_deadline_ns(QEMUTimerList *timer_list)
 {
     int64_t delta;
-    int64_t expire_time;
+    int64_t expire_time = -1;
 
     if (!qatomic_read(&timer_list->active_timers)) {
         return -1;
-- 
2.27.0

[PATCH 5/6] plugins/loader: fix uninitialized variable warning in plugin_reset_uninstall()

[Chen Qun]

After the WITH_QEMU_LOCK_GUARD macro is added, the compiler cannot identify
 that the statements in the macro must be executed. As a result, some variables
 assignment statements in the macro may be considered as unexecuted by the compiler.

The compiler showed warning:
plugins/loader.c: In function ‘plugin_reset_uninstall’:
plugins/loader.c:382:15: warning: ‘ctx’ may be used uninitialized in this function [-Wmaybe-uninitialized]
 382 |     data->ctx = ctx;
     |     ~~~~~~~~~~^~~~~

Add a default value for 'expire_time' to prevented the warning.

Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
---
Cc: "Alex Bennée" <alex.bennee@linaro.org>
---
 plugins/loader.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/plugins/loader.c b/plugins/loader.c
index 8ac5dbc20f..88593fe138 100644
--- a/plugins/loader.c
+++ b/plugins/loader.c
@@ -367,7 +367,7 @@ void plugin_reset_uninstall(qemu_plugin_id_t id,
                             bool reset)
 {
     struct qemu_plugin_reset_data *data;
-    struct qemu_plugin_ctx *ctx;
+    struct qemu_plugin_ctx *ctx = NULL;
 
     WITH_QEMU_LOCK_GUARD(&plugin.lock) {
         ctx = plugin_id_to_ctx_locked(id);
-- 
2.27.0

Re: [PATCH 5/6] plugins/loader: fix uninitialized variable warning in plugin_reset_uninstall()

[Philippe Mathieu-Daudé]

On 11/3/20 2:52 AM, Chen Qun wrote:
> After the WITH_QEMU_LOCK_GUARD macro is added, the compiler cannot identify
>  that the statements in the macro must be executed. As a result, some variables
>  assignment statements in the macro may be considered as unexecuted by the compiler.
> 
> The compiler showed warning:
> plugins/loader.c: In function ‘plugin_reset_uninstall’:
> plugins/loader.c:382:15: warning: ‘ctx’ may be used uninitialized in this function [-Wmaybe-uninitialized]

This shouldn't happen as the function returns before
(else there is a NULL deref).

>  382 |     data->ctx = ctx;
>      |     ~~~~~~~~~~^~~~~
> 
> Add a default value for 'expire_time' to prevented the warning.
> 
> Reported-by: Euler Robot <euler.robot@huawei.com>
> Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
> ---
> Cc: "Alex Bennée" <alex.bennee@linaro.org>
> ---
>  plugins/loader.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/plugins/loader.c b/plugins/loader.c
> index 8ac5dbc20f..88593fe138 100644
> --- a/plugins/loader.c
> +++ b/plugins/loader.c
> @@ -367,7 +367,7 @@ void plugin_reset_uninstall(qemu_plugin_id_t id,
>                              bool reset)
>  {
>      struct qemu_plugin_reset_data *data;
> -    struct qemu_plugin_ctx *ctx;
> +    struct qemu_plugin_ctx *ctx = NULL;
>  
>      WITH_QEMU_LOCK_GUARD(&plugin.lock) {
>          ctx = plugin_id_to_ctx_locked(id);
> 

RE: [PATCH 5/6] plugins/loader: fix uninitialized variable warning in plugin_reset_uninstall()

[Chenqun (kuhn)]

> -----Original Message-----
> From: Philippe Mathieu-Daudé [mailto:philmd@redhat.com]
> Sent: Tuesday, November 3, 2020 10:18 AM
> To: Chenqun (kuhn) <kuhn.chenqun@huawei.com>; qemu-devel@nongnu.org;
> qemu-trivial@nongnu.org
> Cc: Alex Bennée <alex.bennee@linaro.org>; Zhanghailiang
> <zhang.zhanghailiang@huawei.com>; ganqixin <ganqixin@huawei.com>; Euler
> Robot <euler.robot@huawei.com>
> Subject: Re: [PATCH 5/6] plugins/loader: fix uninitialized variable warning in
> plugin_reset_uninstall()
> 
> On 11/3/20 2:52 AM, Chen Qun wrote:
> > After the WITH_QEMU_LOCK_GUARD macro is added, the compiler cannot
> > identify  that the statements in the macro must be executed. As a
> > result, some variables  assignment statements in the macro may be
> considered as unexecuted by the compiler.
> >
> > The compiler showed warning:
> > plugins/loader.c: In function ‘plugin_reset_uninstall’:
> > plugins/loader.c:382:15: warning: ‘ctx’ may be used uninitialized in
> > this function [-Wmaybe-uninitialized]
> 
> This shouldn't happen as the function returns before (else there is a NULL
> deref).
> 
Yes, in fact, it shouldn't have happened when the program was running.
But after added 'WITH_QEMU_LOCK_GUARD', let the compiler think it might happen.
So, we add a default value, make the compiler happy.

Thanks,
Chen Qun
> >  382 |     data->ctx = ctx;
> >      |     ~~~~~~~~~~^~~~~
> >
> > Add a default value for 'expire_time' to prevented the warning.
> >
> > Reported-by: Euler Robot <euler.robot@huawei.com>
> > Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
> > ---
> > Cc: "Alex Bennée" <alex.bennee@linaro.org>
> > ---
> >  plugins/loader.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/plugins/loader.c b/plugins/loader.c index
> > 8ac5dbc20f..88593fe138 100644
> > --- a/plugins/loader.c
> > +++ b/plugins/loader.c
> > @@ -367,7 +367,7 @@ void plugin_reset_uninstall(qemu_plugin_id_t id,
> >                              bool reset)  {
> >      struct qemu_plugin_reset_data *data;
> > -    struct qemu_plugin_ctx *ctx;
> > +    struct qemu_plugin_ctx *ctx = NULL;
> >
> >      WITH_QEMU_LOCK_GUARD(&plugin.lock) {
> >          ctx = plugin_id_to_ctx_locked(id);
> >

[PATCH 6/6] migration: fix uninitialized variable warning in migrate_send_rp_req_pages()

[Chen Qun]

After the WITH_QEMU_LOCK_GUARD macro is added, the compiler cannot identify
 that the statements in the macro must be executed. As a result, some variables
 assignment statements in the macro may be considered as unexecuted by the compiler.

The compiler showed warning:
migration/migration.c: In function ‘migrate_send_rp_req_pages’:
migration/migration.c:384:8: warning: ‘received’ may be used uninitialized in this function [-Wmaybe-uninitialized]
 384 |     if (received) {
     |        ^

Add a default value for 'received' to prevented the warning.

Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
---
Cc: Juan Quintela <quintela@redhat.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
---
 migration/migration.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/migration/migration.c b/migration/migration.c
index 9bb4fee5ac..de90486a61 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -361,7 +361,7 @@ int migrate_send_rp_req_pages(MigrationIncomingState *mis,
                               RAMBlock *rb, ram_addr_t start, uint64_t haddr)
 {
     void *aligned = (void *)(uintptr_t)(haddr & (-qemu_ram_pagesize(rb)));
-    bool received;
+    bool received = false;
 
     WITH_QEMU_LOCK_GUARD(&mis->page_request_mutex) {
         received = ramblock_recv_bitmap_test_byte_offset(rb, start);
-- 
2.27.0

Re: [PATCH 6/6] migration: fix uninitialized variable warning in migrate_send_rp_req_pages()

[Philippe Mathieu-Daudé]

On 11/3/20 2:52 AM, Chen Qun wrote:
> After the WITH_QEMU_LOCK_GUARD macro is added, the compiler cannot identify
>  that the statements in the macro must be executed. As a result, some variables
>  assignment statements in the macro may be considered as unexecuted by the compiler.
> 
> The compiler showed warning:
> migration/migration.c: In function ‘migrate_send_rp_req_pages’:
> migration/migration.c:384:8: warning: ‘received’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>  384 |     if (received) {
>      |        ^
> 
> Add a default value for 'received' to prevented the warning.
> 
> Reported-by: Euler Robot <euler.robot@huawei.com>
> Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
> ---
> Cc: Juan Quintela <quintela@redhat.com>
> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> ---
>  migration/migration.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/migration/migration.c b/migration/migration.c
> index 9bb4fee5ac..de90486a61 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -361,7 +361,7 @@ int migrate_send_rp_req_pages(MigrationIncomingState *mis,
>                                RAMBlock *rb, ram_addr_t start, uint64_t haddr)
>  {
>      void *aligned = (void *)(uintptr_t)(haddr & (-qemu_ram_pagesize(rb)));
> -    bool received;
> +    bool received = false;
>  
>      WITH_QEMU_LOCK_GUARD(&mis->page_request_mutex) {
>          received = ramblock_recv_bitmap_test_byte_offset(rb, start);
> 

Since this helps static analyzer:
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>

Re: [PATCH 0/6] fix uninitialized variable warning

[Peter Maydell]

On Tue, 3 Nov 2020 at 02:07, Chen Qun <kuhn.chenqun@huawei.com> wrote:
>
> Hi all,
>   There are some variables initialized warnings reported by the compiler,
> even if the default CFLAG for the compiler parameters are uesed.
>
> This serial has added some default values or changed the assignment places for the variablies to fix them.


Hi; if you're reporting/fixing compiler errors/warnings please
can you include the compiler version that produced the error
in the commit message? This is helpful for telling us whether
it's a problem with older compilers or whether this is a new
compiler that checks for some things more carefully.

thanks
-- PMM

RE: [PATCH 0/6] fix uninitialized variable warning

[Chenqun (kuhn)]

> -----Original Message-----
> From: Peter Maydell [mailto:peter.maydell@linaro.org]
> Sent: Tuesday, November 3, 2020 6:15 PM
> To: Chenqun (kuhn) <kuhn.chenqun@huawei.com>
> Cc: QEMU Developers <qemu-devel@nongnu.org>; QEMU Trivial
> <qemu-trivial@nongnu.org>; Zhanghailiang
> <zhang.zhanghailiang@huawei.com>; ganqixin <ganqixin@huawei.com>
> Subject: Re: [PATCH 0/6] fix uninitialized variable warning
> 
> On Tue, 3 Nov 2020 at 02:07, Chen Qun <kuhn.chenqun@huawei.com> wrote:
> >
> > Hi all,
> >   There are some variables initialized warnings reported by the
> > compiler, even if the default CFLAG for the compiler parameters are uesed.
> >
> > This serial has added some default values or changed the assignment places
> for the variablies to fix them.
> 
> 
> Hi; if you're reporting/fixing compiler errors/warnings please can you include
> the compiler version that produced the error in the commit message? This is
> helpful for telling us whether it's a problem with older compilers or whether this
> is a new compiler that checks for some things more carefully.
> 
Oops, I didn't consider that. 
These warnings were reported by GCC 9.3, 

Thanks,
Chen Qun