Re: [PATCH] disas: Fix build with glib2.0 >=2.67.3

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Feb 24, 2021 at 01:07:33PM +0000, Peter Maydell wrote:
> On Wed, 24 Feb 2021 at 11:04, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > So from osdep.h I think something like this is likely sufficient:
> >
> > diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
> > index ba15be9c56..7a1d83a8b6 100644
> > --- a/include/qemu/osdep.h
> > +++ b/include/qemu/osdep.h
> > @@ -126,6 +126,7 @@ extern int daemon(int, int);
> >  #include "glib-compat.h"
> >  #include "qemu/typedefs.h"
> >
> > +extern "C" {
> 
> Needs to be protected by #ifdef so it's only relevant for the
> C++ compiler, right?
> 
> >  /*
> >   * For mingw, as of v6.0.0, the function implementing the assert macro is
> >   * not marked as noreturn, so the compiler cannot delete code following an
> > @@ -722,4 +723,6 @@ static inline int platform_does_not_support_system(const char *command)
> >  }
> >  #endif /* !HAVE_SYSTEM_FUNCTION */
> >
> > +}
> > +
> >  #endif
> >
> >
> > We'll also need to them protect any local headers we use before this point.
> >
> > $ grep #include ../../../include/qemu/osdep.h  | grep -v '<'
> > #include "config-host.h"
> > #include CONFIG_TARGET
> > #include "exec/poison.h"
> > #include "qemu/compiler.h"
> > #include "sysemu/os-win32.h"
> > #include "sysemu/os-posix.h"
> > #include "glib-compat.h"
> > #include "qemu/typedefs.h"
> >
> > and transitively through that list, but I think there's no too many
> > more there.
> 
> Is there anything we can do to make the compiler complain if we
> get this wrong? Otherwise it seems likely that we'll end up
> accidentally putting things inside or outside 'extern "C"'
> declarations when they shouldn't be, as we make future changes
> to our headers.

There's nothing easy I know of to highlight this.  It is more the kind
of thing checkpatch would have to look at - complain if there is
anything which isn't a  preprocessor include directive or comment
before the 'extern'.

> (The other approach would be to try to get rid of the
> C++ in the codebase. We could probably say 'drop vixl
> and always use capstone', for instance.)

Yeah, getting rid of C++ would probably be the sanest solution long
term.

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 :|