[libvirt PATCH v2 01/12] glibcompat: Add G_GNUC_UNUSED to g_auto* definitions for clang

[Daniel P. Berrangé]

On Tue, Sep 14, 2021 at 03:28:12PM +0200, Tim Wiederhake wrote:
> 
> Adding G_GNUC_UNUSED at the usage sites (of which there will be a
> couple hundred), will disable unused variable detection irregardless of
> used compiler, just to work around a bug in one single compiler.

AFAIK, there is /no/ unused variable detection once you start
using g_auto, because there are always auto-inserted calls to
the cleanup funcs that cause the variables to be "used". It
is simply a bug in clang that it doesn't see this, while gcc
does. I don't see ny impact on GCC from adding G_GNUC_UNUSED

> 
> I would rather use "G_GNUC_UNUSED" only for variables / function
> arguments that actually are unused. The lock guard variables are used,
> but at the end of the scope rather than during.
> 
> > We should only re-define the g_auto* macros if we have first submitted
> > this change to GLib upstream and they merged it.
> >
> What are your thoughts on macros (#if/#else'd over __clang__ to include
> G_GNUC_UNUSED as required) like this?
> 
>   #define VIR_LOCK_GUARD_MUTEX(mutex) \
>     g_autoptr(virLockGuard) G_GNUC_UNUSED lockguard ## __COUNTER__ =
> virLockGuardNew(mutex);
>   #define VIR_LOCK_GUARD_OBJECT(object) \
>     g_autoptr(virLockGuard) G_GNUC_UNUSED lockguard ## __COUNTER__ =
> virObjectLockGuard(object);
> 
> or:
> 
>   #define VIR_LOCK_GUARD_MUTEX g_autoptr(virLockGuard) G_GNUC_UNUSED
>   VIR_LOCK_GUARD_MUTEX lock1 = virLockGuardNew(mutex);
>   VIR_LOCK_GUARD_MUTEX lock2 = virObjectLockGuard(object);

Those are reasonable as workarounds, but ultimately g_auto* still
need fixing upstream to add G_GNUC_UNUSED to their definitions.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|