From: Joe Perches <joe@perches.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] seq_file: Use seq_puts when seq_printf has only a format with no args
Date: Sat, 16 Mar 2013 09:15:40 -0700 [thread overview]
Message-ID: <1363450540.2023.30.camel@joe-AO722> (raw)
In-Reply-To: <1363449458.25967.76.camel@gandalf.local.home>
On Sat, 2013-03-16 at 11:57 -0400, Steven Rostedt wrote:
> My macro nastiness is contagious ;-)
True.
> On Sat, 2013-03-16 at 06:50 -0700, Joe Perches wrote:
> > +int (seq_printf)(struct seq_file *m, const char *f, ...)
>
> That's rather ugly. Why not just #undef seq_printf before defining it?
The whole thing is ugly, nasty and hackish.
I kinda like it.
But I don't like unnecessary undefs.
The preprocessor doesn't expand (funcname).
> Anyway, not making va_args a whacky name is dangerous. This is why I add
> those crazy underscores. If someone does:
>
> var = 1;
> va_args[] = "abc";
> seq_printf(m, "%d %s", var, va_args);
The same could be true of fmt and it's
used in lots of macros no?
> What will be printed is:
>
> 1 var, va_args
>
> That will be very confusing to people.
And so be fixed very quickly.
> > + if (sizeof(va_args) > 1) \
> > + seq_printf(seq, fmt, ##__VA_ARGS__); \
> > + else \
> > + seq_puts(seq, fmt); \
> > +} while (0)
>
> BTW, you need to return a value.
Oh, yeah, thanks.
> #define seq_printf(seq, fmt, ...) \
> -do { \
> +({ \
> char va_args[] = __stringify(__VA_ARGS__); \
> + int _____ret; \
> if (sizeof(va_args) > 1) \
> - seq_printf(seq, fmt, ##__VA_ARGS__); \
> + _____ret = seq_printf(seq, fmt, ##__VA_ARGS__); \
> else \
> - seq_puts(seq, fmt); \
> -} while (0)
> + _____ret = seq_puts(seq, fmt); \
> + _____ret; \
> +})
It's certainly better as a statement expression,
but I think the underscores are really ugly and
not necessary as ret is locally scoped.
Checkpatch doesn't generally parse strings.
checking strings for % could be done though
I suppose.
next prev parent reply other threads:[~2013-03-16 16:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-16 13:50 Joe Perches
2013-03-16 15:43 ` Bjorn Helgaas
2013-03-16 16:11 ` Steven Rostedt
2013-03-16 17:42 ` Joe Perches
2013-03-16 17:51 ` Joe Perches
2013-03-16 18:01 ` Al Viro
2013-03-16 19:21 ` Steven Rostedt
2013-03-19 3:11 ` [PATCH] checkpatch: Prefer seq_puts to seq_printf Joe Perches
2013-03-16 15:57 ` [RFC PATCH] seq_file: Use seq_puts when seq_printf has only a format with no args Steven Rostedt
2013-03-16 16:15 ` Joe Perches [this message]
2013-03-16 17:02 ` Steven Rostedt
2013-03-16 17:54 ` Al Viro
2013-03-18 20:59 ` Andrew Morton
2013-03-19 2:41 ` Joe Perches
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=1363450540.2023.30.camel@joe-AO722 \
--to=joe@perches.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=viro@zeniv.linux.org.uk \
/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
all inboxes | Powered by JetHome®