Subject: Re: linux-next: Tree for March 11 (tracing)

From: Randy Dunlap <[email-masked]>
Date: Wed, 18 Mar 2009 08:46:51 -0700

On Thu, 12 Mar 2009 12:26:21 -0400 Steven Rostedt wrote:

> 
> On Thu, 2009-03-12 at 09:17 -0700, Randy Dunlap wrote:
> > [adding cc:s]
> > 
> > [same report for March 12]
> > 
> > Randy Dunlap wrote:
> > > Stephen Rothwell wrote:
> > >> Hi all,
> > >>
> > >> Changes since 20090310:
> > > 
> > > 
> > > Building on i386 generates a ton of printk format warnings:
> > > 
> > > kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 5 has type 'unsigned int'
> > > kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 6 has type 'unsigned int'
> > > kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 9 has type 'unsigned int'
> > > kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 10 has type 'unsigned int'
> > > kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 13 has type 'unsigned int'
> > > kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 14 has type 'unsigned int'
> > > kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 17 has type 'unsigned int'
> > > kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 18 has type 'unsigned int'
> > > kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 21 has type 'unsigned int'
> > > kernel/trace/trace_events.c:470: warning: format '%lu' expects type 'long unsigned int', but argument 22 has type 'unsigned int'
> > > 
> 
> I believe this is corrected in Ingo's tip tree. I changed %lu to %zu to
> handle the "sizeof()" case. The fix was suggested by Andrew Morton.

This build warning is still around (20090318).
Is the fix not in some branch that is imported into linux-next or what?

Thanks,
---
~Randy