On Mon, Sep 28, 2020 at 03:32:45PM +0100, Peter Maydell wrote: > On Mon, 28 Sep 2020 at 15:23, Daniel P. Berrangé <berra...@redhat.com> wrote: > > > > On Mon, Sep 28, 2020 at 03:14:45PM +0100, Peter Maydell wrote: > > > On Mon, 28 Sep 2020 at 15:06, Daniel P. Berrangé <berra...@redhat.com> > > > wrote: > > > > I think this can be simplified even more by using GLib's macros > > > > > > > > #define GCC_FMT_ATTR(n, m) G_GNUC_PRINTF(n, m) > > > > > > At least on my system G_GNUC_PRINTF() expands to > > > __format__(__printf__,...), not gnu_printf, so it is > > > not quite what we want. (The difference is that on Windows > > > hosts we still want to mark up our our logging functions as > > > taking the glibc style format handling, not whatever the > > > MS C library format escapes happen to be.) > > > At a minimum you'd need to keep in the "on Windows, > > > redefine __printf__ to __gnu_printf__" logic. > > > > > > See also commit 95df51a4a02a853. > > > > Oh, that's a bug in old GLib versions. I thought we had a new enough > > min to avoid that problem, but i guess not after all. > > Looks like the implementation changed 2 years ago: > https://gitlab.gnome.org/GNOME/glib/-/commit/98a0ab929d8c59ee27e5f470f11d077bb6a56749 > not sure which glib version that would correspond to.
Looks like 2.58.0, which is still a fair bit newer than our 2.48 min. NB, only the macro changed - they were using GNU printf impl for many many years before that but simply had the wrong macro definition We can just sacrifice -Wformat checking for Windows builds when using old GLib. People building natively on Windows with MSys probably have brand new GLib, and those using Fedora mingw / Debian MXE also have pretty new GLib. 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 :|
