Re: [PATCH 05/12] compiler.h: drop __printf__ macro MinGW/glib workaround

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

On Wed, Mar 16, 2022 at 02:41:41PM +0000, Peter Maydell wrote:
> On Wed, 16 Mar 2022 at 13:44, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Thu, Feb 24, 2022 at 08:14:47PM +0000, Peter Maydell wrote:
> > > On Thu, 24 Feb 2022 at 19:50, Marc-André Lureau
> > > <marcandre.lureau@gmail.com> wrote:
> > > > On Thu, Feb 24, 2022 at 11:23 PM Peter Maydell <peter.maydell@linaro.org> wrote:
> > > >> You're probably building with a newer glib, and possibly also
> > > >> a newer mingw.
> > > >>
> > > >> I've cc'd Stefan Weil who might know whether we can drop this
> > > >> workaround as far as the mingw part is concerned.
> > > >
> > > >
> > > > Probably safer to keep it until we bump glib dependency to >=2.58.
> > > >
> > > > I would move it to glib-compat.h though, and leave a note there, as it is (or should be ) an old glib specific workaround.
> > >
> > > We can only move it to glib-compat if we confirm that only the
> > > glib-related part of the workaround is still relevant and the
> > > mingw side is now no longer needed, though.
> >
> > We know glib uses the GNU printf semantics for all its APIs.
> >
> > We know QEMU code will use the GNU printf annotation for all its
> > APIs where it knows it has GNU printf, due to delegating to
> > GLib.
> >
> > For 3rd party libraries, we can have no confidence about whether
> > they expect GNU or native printf format, unless we're doing
> > something to override the printf family of functions at link
> > time. IIRC, we're not doing that, so we can't assume 3rd party
> > stuff expects GNU format, and so the sooner we get rid of
> > the #define __printf__ __gnu_printf__ the better IMHO. The
> > proof of course would be to see a CI test run with the define
> > removed proving that no code we call relies on it.
> 
> Yes, the workaround is definitely correct for QEMU's own
> code and for glib itself. We don't care about 3rd party
> libraries because we don't use any of those which take
> format-string arguments AFAIK. The 'mingw' part AIUI is
> purely for mingw itself, ie the standard library. What
> I'm asking is "what were the versions of mingw that were
> affected by this, and are they all old enough we don't need
> to care from that point of view?".

I've no idea about affected versions, but if they're more than
2 years old I'd say we don't need to care. The various places
you get mingw prebuilt all tend to stay close to the cutting
edge.

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