public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Alex Elder <aelder@sgi.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com
Subject: Re: xfsprogs: fix some printf() warnings that show up for ia64 builds
Date: Tue, 20 Sep 2011 21:02:13 -0500	[thread overview]
Message-ID: <1316570533.3348.6.camel@doink> (raw)
In-Reply-To: <20110920230546.GK15688@dastard>

On Wed, 2011-09-21 at 09:05 +1000, Dave Chinner wrote:
> On Tue, Sep 20, 2011 at 01:43:13PM -0500, Alex Elder wrote:
> > This applies on top of Christoph Hellwig's recent "xfs_repair: add
> > printf format checking and fix the fallout" patch.  It extends the
> > fixes for warnings beyond just xfs_repair and across everything in
> > xfsprogs.
> > 
> > It builds cleanly on ia64 and x86_64, and builds without any
> > printf() format-related warnings on i386.
> > 
> > Signed-off-by: Alex Elder <aelder@sgi.com>
> > 
> > ---
> >  io/parent.c              |   28 ++++++++++++++++------------
> >  logprint/log_misc.c      |   34 ++++++++++++++++++++--------------
> >  logprint/log_print_all.c |   16 ++++++++++------
> >  repair/dinode.c          |   20 ++++++++++++--------
> >  repair/scan.c            |   14 +++++++++-----
> >  5 files changed, 67 insertions(+), 45 deletions(-)
> > 
> > Index: b/io/parent.c
> > ===================================================================
> > --- a/io/parent.c
> > +++ b/io/parent.c
> > @@ -52,12 +52,12 @@ check_parent_entry(xfs_bstat_t *bstatp,
> >         if (sts != 0) {
> >                 fprintf(stderr,
> >                         _("inode-path for inode: %llu is incorrect - path \"%s\" non-existent\n"),
> > -                       bstatp->bs_ino, fullpath);
> > +                       (unsigned long long) bstatp->bs_ino, fullpath);
> 
> Hmmm, didn't Christoph fix these inode number warnings by changing
> the format specifier to PRIU64, not by adding casts? bs_ino is
> defined as:
> 
> 	__u64		bs_ino;
> 
> So PRIu64 is the right thing to do, isn't it?

I haven't checked right now but I wrote a small thesis
in an e-mail a few months ago about it.  But as I recall
uint64_t was defined based on long on some architectures
and based on long long in others.  And __u64 is based
on long long everywhere in the kernel.  Something like
that.  OK, I went and found it.

http://oss.sgi.com/archives/xfs/2011-07/msg00399.html

The problem lies in the kernel, which defines
__u64 as a an (unsigned long) in ia64, but as
(unsigned long long) in x86_64.  This would be
fine, except that the user space code uses
(unsigned long) as u_int64_t for both architectures
(and that, after all is what PRIu64 is for).

Hence for inodes (and anything else defined as
a __u64) you have to use explicit casts because
PRIu64 won't always work for you.

					-Alex
> 
> Either way would work, but being consistent would be good. ;)
> 
> ....
> 
> > ===================================================================
> > --- a/logprint/log_misc.c
> > +++ b/logprint/log_misc.c
> > @@ -307,12 +307,14 @@ xlog_print_trans_buffer(xfs_caddr_t *ptr
> >                          */
> >                         memmove(&x, *ptr, sizeof(__be64));
> >                         memmove(&y, *ptr+8, sizeof(__be64));
> > -                       printf(_("icount: %lld  ifree: %lld  "),
> > -                               be64_to_cpu(x), be64_to_cpu(y));
> > +                       printf(_("icount: %llu  ifree: %llu  "),
> > +                               (unsigned long long) be64_to_cpu(x),
> > +                               (unsigned long long) be64_to_cpu(y));
> 
> Same for al the be64_to_cpu() functions - their return type is
> __u64, too.
> 
> >                                         forkname);
> > @@ -1374,7 +1376,7 @@ process_lclinode(
> >                                                 XFS_DFORK_DSIZE(dip, mp)) {
> >                 do_warn(
> >         _("local inode %" PRIu64 " data fork is too large (size = %lld, max = %d)\n"),
> > -                       lino, be64_to_cpu(dip->di_size),
> > +                       lino, (unsigned long long) be64_to_cpu(dip->di_size),
> 
> That format specifier is wrong - it is %lld. Should be %llu, or
> PRIu64 as previously mentioned without the cast.
> 
> Cheers,
> 
> Dave.



_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2011-09-21  2:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-14 20:12 xfs_repair: add printf format checking and fix the fallout Christoph Hellwig
2011-08-29  8:38 ` Christoph Hellwig
2011-08-30  5:22   ` Dave Chinner
2011-08-30  8:57     ` Christoph Hellwig
2011-09-20 18:43       ` xfsprogs: fix some printf() warnings that show up for ia64 builds Alex Elder
2011-09-20 23:05         ` Dave Chinner
2011-09-21  2:02           ` Alex Elder [this message]
2011-09-19 22:39 ` xfs_repair: add printf format checking and fix the fallout Alex Elder
  -- strict thread matches above, loose matches on Subject: below --
2011-07-18 18:26 xfsprogs: fix some printf() warnings that show up for ia64 builds Alex Elder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1316570533.3348.6.camel@doink \
    --to=aelder@sgi.com \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox