[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