Re: [Qemu-devel] Hacks for building on gcc 7 / Fedora 26

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Eric Blake (eblake@redhat.com) wrote:
> On 07/17/2017 12:36 PM, Peter Maydell wrote:
> > On 17 July 2017 at 18:29, Eric Blake <eblake@redhat.com> wrote:
> >> On 07/17/2017 11:46 AM, Dr. David Alan Gilbert wrote:
> >>
> >>>> +++ w/hw/usb/bus.c
> >>>> @@ -407,8 +407,9 @@ void usb_register_companion(const char *masterbus,
> >>>> USBPort *ports[],
> >>>>  void usb_port_location(USBPort *downstream, USBPort *upstream, int portnr)
> >>>>  {
> >>>>      if (upstream) {
> >>>> -        snprintf(downstream->path, sizeof(downstream->path), "%s.%d",
> >>>> -                 upstream->path, portnr);
> >>>> +        int l = snprintf(downstream->path, sizeof(downstream->path),
> >>>> "%s.%d",
> >>>> +                         upstream->path, portnr);
> >>>> +        assert(l < sizeof(downstream->path));
> >>>
> >>> You may find this doesn't help in some windows builds;  the assert
> >>> functions aren't always marked as noreturn (because they pop up a dialog
> >>> that asks you whether you want to run into a debugger etc).
> >>
> >> How would it not help?  Are we using gcc 7 on windows builds?
> > 
> > At some point in the future we are likely to, because my
> > w32/w64 test setups use the Ubuntu gcc-mingw-w64-x86-64
> > packages, and so as I upgrade my desktop they will move
> > forward to newer gcc versions. (More generally our users
> > may do so before me ;-))
> 
> So, does gcc's warning actually depend on the no-return-ness of the
> assert() statement added here?

I'm not sure in this case, I'd hit it previously though, see my comment
from 2015 in:
   https://sourceforge.net/p/mingw-w64/bugs/306/

> Would there be anything wrong with making osdep.h do this on mingw:
> 
> #include <assert.h>
> #undef assert
> #define assert(expr) g_assert(expr)
> 
> so that we can reliably get no-return handling that we desire, without
> having to audit lots of other code?

It's a bit nasty, but hmm.
I only just about trust glib not to change, all of the fancier g_assert
variants can return, but g_assert is still safe.

Dave

> > 
> > We should be consistent -- if we can't trust assert() to
> > be marked nonreturn, as it seems we can't, then we shouldn't
> > write new code that assumes it always is, even if today
> > it doesn't happen to bite us on the compiler/host combinations
> > we're testing right now.
> 
> -- 
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.           +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org
> 



--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK