On Wed, Mar 16, 2022 at 02:41:41PM +0000, Peter Maydell wrote: > On Wed, 16 Mar 2022 at 13:44, Daniel P. Berrangé <berra...@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.lur...@gmail.com> wrote: > > > > On Thu, Feb 24, 2022 at 11:23 PM Peter Maydell > > > > <peter.mayd...@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 :|
