This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: printf and glibc extensions
- From: Duane Ellis <duane at duaneellis dot com>
- To: Eric Blake <ebb9 at byu dot net>
- Cc: newlib at sources dot redhat dot com
- Date: Fri, 13 Apr 2007 00:55:09 -0400
- Subject: Re: printf and glibc extensions
- References: <461EFB2A.6080608@byu.net>
Eric Blake wrote:
Is there any interest in the following glibc extensions to printf?
newlib is nice because it is is specifically _NOT_ the bloated monster
glibc.
Is the goal a glibc clone? If so, the rhetorical question becomes: Why
not just use glibc?
And leave newlib alone..
In your defense, standards are always a good thing.
But to answer your question, it depends on your _target_ .
For embedded, bloat=bad, in my micro controller world: I have 64K of
flash, nothing more.
Others have megabytes.
Perhaps, a --enable-newlib-lean-and-mean is needed....
Obviously, the new extensions would need to be controlled by a configure
time switch (and perhaps some of the old ones grouped into that switch, so
that a strict environment has smaller code size). I'm thinking
- --enablie-newlib-io-extensions, similar to the existing
- --enable-newlib-io-pos-args, --enable-newlib-io-long-long, and
- --enable-newlib-io-long-double.
There are too many --enable-this-funky-feature-options.
Worse, you must dig through levels of ./configure to find the one you need.
And I just suggested '--enable-newlib-lean-and-mean' .....
--Duane.