Here is my benchmark just to show I am not speaking out of an imaginary
world:
#include <stdio.h>
int main()
{
const char *buff = "foo";
int i = 0;
for (i; i < 1000000; ++i)
// fputs(buff, stdout);
printf("%s", buff);
return 0;
}
Fputs:
real 0m1.761s
user 0m0.047s
sys 0m0.007s
Printf:
real 0m2.811s
user 0m0.097s
sys 0m0.020s
On Thu, Aug 14, 2014 at 4:15 PM, Laszlo Papp <[email protected]> wrote:
> On Thu, Aug 14, 2014 at 4:05 PM, Rich Felker <[email protected]> wrote:
>
>> On Thu, Aug 14, 2014 at 03:28:51PM +0100, Laszlo Papp wrote:
>> > On Thu, Aug 14, 2014 at 2:44 PM, Tanguy Pruvot <[email protected]
>> >
>> > wrote:
>> >
>> > > its the same with bionic libc (arm)
>> > >
>> > > printf("test") is ok but not printf(buf) with char buf[] = "test";
>> > > printf("%s", buf) is ok
>> > >
>> >
>> > Yeah, I guess it is about personal preference. I personally do not like
>> the
>> > extended code just to make some "smart" option silent. IMHO, it makes
>> the
>> > code needlessly longer by adding another small layer for the content of
>> the
>> > variable. If there is no need for formatting, why use printf in the
>> first
>> > place and not fputs with stdout? IMHO, stdout is nicer than "%s" :-) On
>> the
>> > other hand, it is too bad that there is nothing between fputs and puts
>> > where you do not need to use the file descriptor and you do not get a
>> new
>> > line either.
>>
>> In principle stdout is more expensive than "". stdout is a GOT
>> reference in PIC, and "" is just PC-relative. For non-PIC it makes no
>> difference though.
>>
>
> Then my PC is probably lying since the practice does seem to disagree with
> you, apparently as well as this post:
>
>
> http://stackoverflow.com/questions/17238784/c-puts-without-newline#comment24978835_17238840
>
> (and the one below, ok, it is not critical, but it performs better for
> others, too)
>
> Raw strings are also uglier IMHO than well-defined identifiers, like
> stdout, but that is personal taste, so I do not mind that one.
>
>
>> As for the topic at hand, I don't think it's necessary to make this
>> change if the messages are DOCUMENTED as being format strings that are
>> required not to contain any format specifiers, and there's a big
>> warning to this effect in the source wherever they appear. printf
>> allows format strings chosen (or even constructed) at runtime and the
>> -W option to make this an error is bogus; at least it cannot be
>> applied to code that was not written for a specific coding style that
>> forbids such usage.
>>
>
> Well, the advantage of removing this security risk is that any string can
> be passed without constraining the string anytime.
>
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
