On 07/17/2017 12:36 PM, Peter Maydell wrote:
> On 17 July 2017 at 18:29, Eric Blake <ebl...@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? 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? > > 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
signature.asc
Description: OpenPGP digital signature
