On Tue, Apr 02, 2024 at 12:58:43PM +0300, Vladimir Sementsov-Ogievskiy wrote: > > > Again, same false-positives, because of WITH_GRAPH_RDLOCK_GUARD().. > > > > > > Didn't you try to change WITH_ macros somehow, so that compiler believe > > > in our good intentions? > > > > > > > > > #define WITH_QEMU_LOCK_GUARD_(x, var) \ > > for (g_autoptr(QemuLockable) var = \ > > qemu_lockable_auto_lock(QEMU_MAKE_LOCKABLE_NONNULL((x))); \ > > var; \ > > qemu_lockable_auto_unlock(var), var = NULL) > > > > I can't think of a clever way to rewrite this. The compiler probably > > thinks the loop may not run, due to the "var" condition. But how to > > convince it otherwise? it's hard to introduce another variable too.. > > > hmm. maybe like this? > > #define WITH_QEMU_LOCK_GUARD_(x, var) \ > for (g_autoptr(QemuLockable) var = \ > qemu_lockable_auto_lock(QEMU_MAKE_LOCKABLE_NONNULL((x))), \ > var2 = (void *)(true); \ > var2; \ > qemu_lockable_auto_unlock(var), var2 = NULL) > > > probably, it would be simpler for compiler to understand the logic this way. > Could you check?
Wouldn't that attach __attribute__((cleanup(xxx))) to var2, at which point we could cause the compiler to call xxx((void*)(true)) if the user does an early return inside the lock guard, with disastrous consequences? Or is the __attribute__ applied only to the first out of two declarations in a list? -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org
