From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:38618)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1bDagQ-0007s5-MW
	for qemu-devel@nongnu.org; Thu, 16 Jun 2016 13:02:23 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1bDagK-0004Bq-DH
	for qemu-devel@nongnu.org; Thu, 16 Jun 2016 13:02:22 -0400
Received: from mx1.redhat.com ([209.132.183.28]:43685)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1bDagK-0004Bf-8f
	for qemu-devel@nongnu.org; Thu, 16 Jun 2016 13:02:16 -0400
References: <1466086585-16526-1-git-send-email-pbonzini@redhat.com>
	<CAFEAcA-8cbwqVNb-6knUUcfZjyhDJTKxy06p1Z16xBXrGO=z5Q@mail.gmail.com>
	<7a3acf1b-ff2b-e298-bf4e-9e20f1974965@redhat.com>
	<CAFEAcA-D0kygmLyimXo5bbdVd5a=fi6Kky+oH66CWefx1T5=OA@mail.gmail.com>
From: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <cb487871-4284-66cc-fa05-f5318939b33b@redhat.com>
Date: Thu, 16 Jun 2016 19:01:57 +0200
MIME-Version: 1.0
In-Reply-To: <CAFEAcA-D0kygmLyimXo5bbdVd5a=fi6Kky+oH66CWefx1T5=OA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PULL 00/30] KVM, build, NBD,
 SCSI patches for 2016-06-16
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>, Eric Blake <eblake@redhat.com>



On 16/06/2016 18:55, Peter Maydell wrote:
>> > Interesting, I did test clang this time.  I'll fix it but really this
>> > is a compiler bug.  It's *impossible* to pass a short variable
>> > argument, hence va_arg(ap, short) *must* be the same as va_arg(ap, int).
> This one's an OSX/Apple special -- it isn't part of the stock clang.
> (It has its good points -- this is the only 64-bit platform that
> will warn about format string issues that will break compile on
> 32-bit hosts.)
> 
> I guess the point of the warning in this particular case is to
> say "you passed something that could be wider than a short but
> you used a format specifier which is for a short/unsigned short"
> (ie your format might be unintentionally dropping the top 16 bits
> of the data).

Does it fire even of

    void f(unsigned short x)
    {
       printf ("%hx", x | 1);
    }

?

Because technically that's an int too (and that's why I think this
particular warning is not a great thing)...

Paolo