From: Rusty Lynch <rusty@linux.co.intel.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] Request to remove -Wfno-format
Date: Fri Feb 13 21:09:51 2004 [thread overview]
Message-ID: <20040214030940.GA12892@penguin.co.intel.com> (raw)
In-Reply-To: <20040214030500.GA19657@ca-server1.us.oracle.com>
On Fri, Feb 13, 2004 at 07:05:00PM -0800, Manish Singh wrote:
> On Fri, Feb 13, 2004 at 05:37:48PM -0800, Rusty Lynch wrote:
> > On Fri, Feb 13, 2004 at 05:04:24PM -0800, Manish Singh wrote:
> > > On Fri, Feb 13, 2004 at 04:06:54PM -0800, Rusty Lynch wrote:
> > > > On Fri, Feb 13, 2004 at 02:15:37PM -0800, Manish Singh wrote:
> > > > <snip>
> > > > > Well, I really meant "%Zu". 'z' is a modifier that was introduced in C99,
> > > > > but it's only in very recent 2.4.x printk implementations, i.e. none of
> > > > > current AS 2.1, EL3, or UL have it, which means we can't use it. 'Z' is
> > > > > GNU extension (that's deprecated now in favor of the C99 modifier) that
> > > > > *is* in all the printks we need to support, so we should use that.
> > > > > __attribute__ format should know about both anyway.
> > > >
> > > > Any ideas on cleanly printing sector_t? In 2.4 it was always a u32, now it
> > > > is architecture dependent (u32 by default but set to u64 by most architectures
> > > > including ia32 and ia64.)
> > >
> > > I'd suggest always casting to u64 and using %Lu.
> >
> > How would you feel about always casting to (unsigned long long)? u64 is unsigned long
> > on some arch's and unsigned long long on others. Specifically, we get warnings
> > on ia64 and ppc64 since they both define u64 as unsigned long.
>
> Ugh. That's going to be a general problem with all u64 values. Talking with
> Kurt and Mark here, they prefer a U64C define which expands to an unsigned
> long long cast. You're going to need that for the HI/LO removal too.
>
> -Manish
I have something here that instead of doing crazy cast, with define a U64_MODIFIER
that will expand appropriatly. So... it's always correct and much easier on the eyes.
printk's would look something like:
printk(KERN_DEBUG "size_t is %Zu, and a u64 is " U64_MODIFIER "\n", asize, au64value);
Let me do one more verification on the patch and I will send it out.
--rusty
next prev parent reply other threads:[~2004-02-13 21:09 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-12 12:39 [Ocfs2-devel] Request to remove -Wfno-format Rusty Lynch
2004-02-12 12:52 ` Rusty Lynch
2004-02-12 14:30 ` Manish Singh
2004-02-13 16:10 ` Rusty Lynch
2004-02-12 21:44 ` Manish Singh
2004-02-13 16:10 ` Rusty Lynch
2004-02-13 16:15 ` Manish Singh
2004-02-13 16:24 ` Rusty Lynch
2004-02-13 18:07 ` Rusty Lynch
2004-02-13 19:04 ` Manish Singh
2004-02-13 19:37 ` Rusty Lynch
2004-02-13 21:05 ` Manish Singh
2004-02-13 21:09 ` Rusty Lynch [this message]
2004-02-13 21:18 ` Mark Fasheh
2004-02-16 15:01 ` Rusty Lynch
-- strict thread matches above, loose matches on Subject: below --
2004-02-17 8:50 Cahill, Ben M
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=20040214030940.GA12892@penguin.co.intel.com \
--to=rusty@linux.co.intel.com \
--cc=ocfs2-devel@oss.oracle.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.