This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Support %m in printf functions


On Jan  5 14:55, Can Finner wrote:
> On Wed, Jan 4, 2012 at 4:43 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> > On Tuesday 03 January 2012 11:32:02 Eric Blake wrote:
> >> On 01/03/2012 03:37 AM, Richard Earnshaw wrote:
> >> > On 01/01/12 17:59, Yaakov (Cygwin/X) wrote:
> >> >> This patch adds support for the "%m" conversion specifier in the printf
> >> >> and wprintf functions, a GNU extension:
> >> >>
> >> >> http://www.kernel.org/doc/man-pages/online/pages/man3/printf.3.html
> >> >>
> >> >> Patch and STC attached.
> >> >
> >> > Printf is already very bloated. ÂOn bare metal this adds yet more
> >> > overhead for something that's very unlikely to be used.
> >> >
> >> > I think there should be a way of building printf with all GNU extensions
> >> > disabled.
> >>
> >> I very much agree that this needs to be gated if we add it; I also think
> >> that none of the existing gates are appropriate (I see at least these
> >> existing gates _NO_POS_ARGS, _NO_LONGLONG, FLOATING_POINT, _NO_LONGDBL,
> >> _MB_CAPABLE and _WANT_IO_C99_FORMATS), se we'd need a new one, as well
> >> as the configure machinery to enable the gate.
> >
> > +1 ... i've seen people do uClibc on bare-metal because newlib is too bloated
> > for them
> > -mike
> 
> Just for noting.
> 
> Once I did an experiment to measure the benefit of configuration
> options and found "enable-newlib-reent-small" saves only a little more
> than 100 bytes in terms of text/global_data, and even worse if the
> dynamically allocated items are counted.
> Given the small(or NO) gain in code size, this option dramatically
> complicated the implementation.

REENT_SMALL has another purpose.  It doesn't affect immediately what you
safe by using the various options in printf.  The FLOATING_POINT option
should have a big impact in theory.  If you use iprintf rather than
printf in your application, you can, for example, save 6K on i386 just by
not pulling in the printf floating point code.  Additionally you don't
pull in ldtoa, which saves you another 14K of code and data.  These
numbers were taken from the object files in a non-optimized build, but
you get the idea.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]