[CRIU] [PATCH 14/23] cr: introduced the macro P() to convert an integer to unsigned long
Pavel Emelyanov
xemul at parallels.com
Mon Jan 14 06:46:30 EST 2013
On 01/14/2013 03:37 PM, Alexander Kartashov wrote:
> On 01/14/2013 02:56 PM, Pavel Emelyanov wrote:
>>> @@ -216,8 +216,8 @@ static int map_private_vma(pid_t pid, struct vma_area *vma, void *tgt_addr,
>>>> if (p->vma.end == vma->vma.end &&
>>>> p->vma.start == vma->vma.start) {
>>>> pr_info("COW 0x%016lx-0x%016lx 0x%016lx vma\n",
>>>> - vma->vma.start, vma->vma.end, vma->vma.pgoff);
>>>> - paddr = (void *) vma_premmaped_start(&p->vma);
>>>> + P(vma->vma.start), P(vma->vma.end), P(vma->vma.pgoff));
>> print format should be fixed instead
>>
>
> Are you sure? You thought different about this hunk earlier:
I remind I saw the home-brew PRI-something macro from you and objected against
_it_. If we can fix this by using the standard %Lx (can we?) this is OK.
>>> @@ -210,7 +212,7 @@ static int map_private_vma(pid_t pid, struct vma_area *vma, void *tgt_addr,
>>>
>>> if (p->vma.end == vma->vma.end &&
>>> p->vma.start == vma->vma.start) {
>>> - pr_info("COW 0x%016lx-0x%016lx 0x%016lx vma\n",
>>> + pr_info("COW 0x%016"PRIx64"-0x%016"PRIx64" 0x%016"PRIx64" vma\n",
>>> vma->vma.start, vma->vma.end, vma->vma.pgoff);
>
>> WTF is that? It's just unsigned long printing, why this ugly format hacks?!
>
>
More information about the CRIU
mailing list