This is the mail archive of the newlib@sources.redhat.com 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: Is newlib' primary intent still targeted for embedded systemuse?


> From: Jeff Johnston <jjohnstn@redhat.com>
> Newlib is evolving.  It was originally meant to provide a basic C library for
> embedded platforms but it is also being used to provide something functionally
> between that of the basic ANSI C library and glibc.  In many cases, extension
> is 
> made without affecting embedded platforms (e.g. the linux code kept separate
> in 
> libc/sys/linux, certain directories of functions like 64-bit I/O are optional,
> flags can be used to disable features like stdio floating-point).  The other
> thing to remember is that embedded platforms link statically and bring in what
> they use for the most part.  Sometimes newlib drags in unwanted bloat, but in
> such cases, I am totally in favor of adding optional configuration flags to
> aid 
> the smaller platform.  For example, there was talk recently of adding the
> regex 
> functions into vanilla newlib.  If an embedded application doesn't use regex,
> then it shouldn't be affected by the new functions.  If other parts of newlib
> start using the regex functionality beneath the covers, then we should make
> that 
> usage optional.  Ideally, one should be able to configure newlib to one's
> needs.
> 
> Regarding the push to make newlib POSIX-compliant: I have no problem complying
> various functions closer to the POSIX and C99 standards as this can add
> beneficial functionality in many cases.  As well, the addition of some
> commonly 
> used functions can make porting code to use newlib that much easier.  Do I
> ultimately see newlib being made fully POSIX-compliant?  No.  That doesn't
> make 
> sense for embedded platforms and glibc is already there for native platforms.

Thank you, that explanation was very helpful; was especially concerned with
the possible growing interdependence of code, via feature creep, potentially
resulting worst-case in an all or nothing link (which it sounds like you and
others have been trying to keep an eye on to prevent from occurring;
although suspect subtle dependencies on variable type sizes are a bit harder
to keep a handle on; but very nice to know that embedded systems is still
the focus of the project).

Thanks again, -paul-



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