qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 7/7] qobject atomics osdep: Make a few macros more hygieni


From: Philippe Mathieu-Daudé
Subject: Re: [PATCH v3 7/7] qobject atomics osdep: Make a few macros more hygienic
Date: Thu, 21 Sep 2023 14:41:55 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.15.1

On 21/9/23 14:13, Markus Armbruster wrote:
Variables declared in macros can shadow other variables.  Much of the
time, this is harmless, e.g.:

     #define _FDT(exp)                                                  \
         do {                                                           \
             int ret = (exp);                                           \
             if (ret < 0) {                                             \
                 error_report("error creating device tree: %s: %s",   \
                         #exp, fdt_strerror(ret));                      \
                 exit(1);                                               \
             }                                                          \
         } while (0)

Harmless shadowing in h_client_architecture_support():

         target_ulong ret;

         [...]

         ret = do_client_architecture_support(cpu, spapr, vec, fdt_bufsize);
         if (ret == H_SUCCESS) {
             _FDT((fdt_pack(spapr->fdt_blob)));
             [...]
         }

         return ret;

However, we can get in trouble when the shadowed variable is used in a
macro argument:

     #define QOBJECT(obj) ({                                 \
         typeof(obj) o = (obj);                              \
         o ? container_of(&(o)->base, QObject, base) : NULL; \
      })

QOBJECT(o) expands into

     ({
--->    typeof(o) o = (o);
         o ? container_of(&(o)->base, QObject, base) : NULL;
     })

Unintended variable name capture at --->.  We'd be saved by
-Winit-self.  But I could certainly construct more elaborate death
traps that don't trigger it.

To reduce the risk of trapping ourselves, we use variable names in
macros that no sane person would use elsewhere.  Here's our actual
definition of QOBJECT():

     #define QOBJECT(obj) ({                                         \
         typeof(obj) _obj = (obj);                                   \
         _obj ? container_of(&(_obj)->base, QObject, base) : NULL;   \
     })

Works well enough until we nest macro calls.  For instance, with

     #define qobject_ref(obj) ({                     \
         typeof(obj) _obj = (obj);                   \
         qobject_ref_impl(QOBJECT(_obj));            \
         _obj;                                       \
     })

the expression qobject_ref(obj) expands into

     ({
         typeof(obj) _obj = (obj);
         qobject_ref_impl(
             ({
--->            typeof(_obj) _obj = (_obj);
                 _obj ? container_of(&(_obj)->base, QObject, base) : NULL;
             }));
         _obj;
     })

Unintended variable name capture at --->.

The only reliable way to prevent unintended variable name capture is
-Wshadow.

One blocker for enabling it is shadowing hiding in function-like
macros like

      qdict_put(dict, "name", qobject_ref(...))

qdict_put() wraps its last argument in QOBJECT(), and the last
argument here contains another QOBJECT().

Use dark preprocessor sorcery to make the macros that give us this
problem use different variable names on every call.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
---
  include/qapi/qmp/qobject.h | 10 ++++++++--
  include/qemu/atomic.h      | 17 ++++++++++++-----
  include/qemu/compiler.h    |  3 +++
  include/qemu/osdep.h       | 27 ++++++++++++++++++++-------
  4 files changed, 43 insertions(+), 14 deletions(-)

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]