Messages in this thread |  | | | Date | Mon, 14 Apr 2008 04:40:49 -0400 | | From | Jakub Jelinek <> | | Subject | Re: linux-next: Tree for April 10 (arch/x86) |
| |
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
|  |