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: printf and glibc extensions


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.




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