Re: linux-next: Tree for April 10 (arch/x86)

[Jakub Jelinek <jakub@redhat.com>]

On Fri, Apr 11, 2008 at 08:19:01AM -0700, Randy Dunlap wrote:
> On Fri, 11 Apr 2008 09:46:31 +0200 Ingo Molnar wrote:
> 
> > 
> > * Randy Dunlap <randy.dunlap@oracle.com> wrote:
> > 
> > > Fix printk formats in x86/mm/ioremap.c:
> > > 
> > > next-20080410/arch/x86/mm/ioremap.c:137: warning: format '%llx' expects type 'long long unsigned int', but argument 2 has type 'resource_size_t'
> > > next-20080410/arch/x86/mm/ioremap.c:188: warning: format '%llx' expects type 'long long unsigned int', but argument 2 has type 'resource_size_t'
> > > next-20080410/arch/x86/mm/ioremap.c:188: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'long unsigned int'
> > 
> > thanks, applied.
> > 
> > >  	if (!phys_addr_valid(phys_addr)) {
> > >  		printk(KERN_WARNING "ioremap: invalid physical address %llx\n",
> > > -		       phys_addr);
> > > +		       (unsigned long long)phys_addr);
> > 
> > is there really no way to solve this more cleanly than a forced cast?
> 
> I haven't seen any other decent solutions.  This is what we do
> all over the kernel.

You can define macros and use them in the format string.
In this case
		printk(KERN_WARNING "ioremap: invalid physical address %" PRIRESOURCESZ "\n",
		       phys_addr);
(see the PRI* macros in
http://www.opengroup.org/onlinepubs/009695399/basedefs/inttypes.h.html
and e.g. glibc inttypes.h to see how it is defined).  Other alternative is
custom format length modifiers, but unfortunately there is no easy way ATM
to teach GCC about them.

	Jakub