qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL 00/57] Migration pull


From: Eric Blake
Subject: Re: [Qemu-devel] [PULL 00/57] Migration pull
Date: Mon, 9 Nov 2015 15:36:10 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 11/09/2015 11:29 AM, Juan Quintela wrote:

>> Fails to build on W32:
> 
> I know it is not good consolation, but it build for me and David.
> And I don't understand the error.

The error is a bug in mingw headers.

> 
> 
>>
>> cc1: warnings being treated as errors
>> /home/petmay01/linaro/qemu-for-merges/migration/migration.c: In
>> function ‘source_return_path_thread’:
>> /home/petmay01/linaro/qemu-for-merges/migration/migration.c:1289:
>> warning: format ‘%zd’ expects type ‘signed size_t’, but argument 5 has
>> type ‘ssize_t’
> 
> expect ""signed size_t""  but receives ssize_t?  I think the one wrong
> is your compiler no?

Usually this is a sign of a system with buggy headers where size_t and
ssize_t are the same size (32-bits) but different underlying types (one
based on 32-bit long, the other on 32-bit int).  [There are worse cases
of 64-bit size_t and 32-bit ssize_t on some fringe platforms, but I
don't think qemu caters to any of those].

> 
>>From wikipedia:
> 
>   size_t is guaranteed to be at least 16 bits wide. Additionally, POSIX
>   includes ssize_t, which is a signed integral type of the same width as
>   size_t.
> 

Wikipedia lies.  POSIX does NOT require ssize_t to be the same width as
size_t [although any modern system that invokes that corner of POSIX
permission deserves to be shot for poor quality of implementation].

> Notice that I don't claim to fully understand the size_t/ssize_t
> difference.

The only POSIX-ly correct portable way to print ssize_t is via casts
(yes, quite ugly), as in:

printf("%zu", (size_t)(ssize_t_value));

I wish %zd were portably useful for printing ssize_t, but POSIX hasn't
yet made that requirement.  And while I argue that mingw headers are
broken (because they aren't doing the obvious implementation of size_t
and ssize_t based on the same underlying type), it's also hard to argue
that it is violating POSIX (since POSIX doesn't yet require the same
underlying type).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]