missing format string in applets/usage_pod.c

[Laszlo Papp]

On Fri, Aug 15, 2014 at 6:31 PM, Rich Felker <dalias at libc.org> wrote:

> On Thu, Aug 14, 2014 at 11:58:56PM -0700, Isaac Dunham wrote:
> > On Thu, Aug 14, 2014 at 04:15:50PM +0100, Laszlo Papp wrote:
> > > On Thu, Aug 14, 2014 at 4:05 PM, Rich Felker <dalias at libc.org> 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 <
> tanguy.pruvot at gmail.com>
> > > > > 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.
> >
> > printf() is almost always going to call vfprintf(stdout, fmt, ap);
> > I've checked musl, uclibc, glibc, and netbsd; dietlibc is the only
> > exception I've found, and it's ugly and does not have locking/retry/...
> > newlib calls _vfprintf_r, which is almost the same concept.
> > Meanwhile, printf has to do the formatting.
> >
> > In other words:
> > Just because printf("%s", string) doesn't name stdout, don't assume that
> > it doesn't use a reference to stdout.
> > So an ACK for Laszlo Papp's recommendation of fputs().
>
> I was talking about code size overhead, not run time overhead. Of
> course there's a reference to stdout in printf. When you reference it
> again yourself, that's a second reference. It's not a big deal but
> apparently busybox folks care about this kind of micro-optimization...
>

Why not care if it is better and it has no disadvantage?

The size complaint does not matter since that "size overhead" is already in
the lib pointed out by Isaac. It will not automagically know to print to
stdout.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20140815/3db36a8e/attachment-0001.html>