Re: [PATCH] Support %m in printf functions

[Can Finner <can dot finner at gmail dot com>]

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.
Some other options may not work as expected, either.

So It would be great to have all these configuration gates
reconsidered and cleaned,
then we could refactor and optimize the library for long term.

-- 
Regards.