[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87twyqxbj4.fsf@rasmusvillemoes.dk>
Date: Fri, 13 Feb 2015 13:04:47 +0100
From: Rasmus Villemoes <linux@...musvillemoes.dk>
To: David Laight <David.Laight@...LAB.COM>
Cc: Mark Rustad <mrustad@...il.com>,
"Rustad\, Mark D" <mark.d.rustad@...el.com>,
Stanislaw Gruszka <sgruszka@...hat.com>,
Kalle Valo <kvalo@...eaurora.org>,
"linux-wireless\@vger.kernel.org" <linux-wireless@...r.kernel.org>,
"netdev\@vger.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] iwl4965: Enable checking of format strings
On Fri, Feb 13 2015, David Laight <David.Laight@...LAB.COM> wrote:
> From: Rasmus Villemoes
>> Well, probably the linker is allowed to overlap "anonymous" objects
>> (string literals) with whatever const char[] (or indeed any const)
>> object it finds containing the appropriate byte sequence. But I think
>> language lawyers would insist that for
>>
>> const char foo[] = "a string";
>> const char bar[] = "a string";
>
> A quick test shows those are separate strings.
> But 'const char *foo = "xxx";' will share.
Yes, of course, because in that case you are actually creating two
objects, "xxx" which the linker will find some place to put, and foo
which is initialized to the address of whereever "xxx" was/will be
put. So one is wasting sizeof(const char*). Also, passing foo to a
function means the compiler has to load the value of foo and use that,
instead of simply passing the compile-time (well, link-time) constant
address of "xxx".
> You also need -O1 to get the strings into .rodata.str.n so that the linker
> can merge them.
Sure, optimization has to be turned on, but isn't the kernel always
compiled with -O2? ISTR that there are some things which won't even
work/compile with -O0.
Rasmus
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists