[Top][All Lists]

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

Re: [Qemu-ppc] [Qemu-devel] [PATCH 2/2] target-ppc: Cast ssize_t to size

From: Stefan Weil
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH 2/2] target-ppc: Cast ssize_t to size_t before printing with %zx
Date: Wed, 24 Dec 2014 10:47:32 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0

Am 23.12.2014 um 23:47 schrieb Peter Maydell:
> On 23 December 2014 at 22:36, Stefan Weil <address@hidden> wrote:
>> Am 23.12.2014 um 23:22 schrieb Peter Maydell:
>>> --- a/hw/ppc/spapr.c
>>> +++ b/hw/ppc/spapr.c
>>> @@ -1438,7 +1438,7 @@ static void ppc_spapr_init(MachineState *machine)
>>>       }
>>>       if (spapr->rtas_size > RTAS_MAX_SIZE) {
>>>           hw_error("RTAS too big ! 0x%zx bytes (max is 0x%x)\n",
>>> -                 spapr->rtas_size, RTAS_MAX_SIZE);
>>> +                 (size_t)spapr->rtas_size, RTAS_MAX_SIZE);
>>>           exit(1);
>>>       }
>>>       g_free(filename);
>> Which compiler did you use? I get no warning with Debian's
>> x86_64-w64-mingw32-gcc 4.6.3 or
>> native MinGW-w32 compilers.
> $ i586-mingw32msvc-gcc --version
> i586-mingw32msvc-gcc (GCC) 4.2.1-sjlj (mingw32-2)
> Yes, this is ancient... it's from the Debian mingw32 package.
> I just use this for compile testing, not for trying to run.
> I should probably switch to the w64 compiler for build tests;
> I forget now if there was a reason why I hadn't.
> I suspect, as I say, that this is just a generic old-gcc bug,
> but it's the only one in the codebase, so it seems easiest
> just to fix it.
> -- PMM

"git grep" finds 6 "%zx", 66 "%zu" and 80 "%zd" in my QEMU source tree.
Some of those are in debug traces, others are conditionally compiled
depending on your configuration. Are you sure that none of those needs
the same kind of modification, too? I don't thing fixing one of them for
an ancient compiler is worth the trouble of explaining why there is a
type cast.

What about using hwaddr instead of ssize_t for rtas_size (and
HWADDR_PRIx in the format string)? It looks like that would be more
consistent with the rest of the code. See for example the arguments of
function spapr_finalize_fdt.


reply via email to

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