From: Kevin Easton <kevin@guarana.org>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Manuel Sch?lling <manuel.schoelling@gmx.de>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fs: Cleanup string initializations (char[] instead of char *)
Date: Mon, 19 May 2014 11:51:38 +1000 [thread overview]
Message-ID: <20140519015138.GA5639@chicago.guarana.org> (raw)
In-Reply-To: <20140517165345.GG18016@ZenIV.linux.org.uk>
On Sat, May 17, 2014 at 05:53:45PM +0100, Al Viro wrote:
> On Sat, May 17, 2014 at 05:00:18PM +0200, Manuel Sch?lling wrote:
> > Initializations like 'char *foo = "bar"' will create two variables: a static
> > string and a pointer (foo) to that static string. Instead 'char foo[] = "bar"'
> > will declare a single variable and will end up in shorter
> > assembly (according to Jeff Garzik on the KernelJanitor's TODO list).
>
> The hell it will. Compare assembler generated e.g. for 32bit x86 before
> and after.
>
> > {
> > char *dp;
> > char *status = "disabled";
> > - const char * flags = "flags: ";
> > + const char flags[] = "flags: ";
>
> The first variant puts address of constant array into local variable
> (on stack or in a register). The second one fills local _array_ - the
> string itself goes on stack.
Right - if you're going to do this, you ireally want to make the array
static as well:
static const char flags[] = "flags: ";
(it's very unlikely that you would want a const array that isn't static).
As Al showed though, usually the optimiser will figure things out on its
own, and the pointer variable in the original variant gets optimised away.
There's also optimisations that apply to string literals but don't apply to
arrays, like string literal merging, which mean that the original could
well still be preferred.
- Kevin
prev parent reply other threads:[~2014-05-19 0:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-17 15:00 Manuel Schölling
2014-05-17 15:44 ` Mateusz Guzik
2014-05-17 17:21 ` Al Viro
2014-05-17 17:58 ` Mateusz Guzik
2014-05-17 16:53 ` Al Viro
2014-05-18 10:01 ` Manuel Schoelling
2014-05-19 1:51 ` Kevin Easton [this message]
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=20140519015138.GA5639@chicago.guarana.org \
--to=kevin@guarana.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manuel.schoelling@gmx.de \
--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®