Re: clearenv for newlib

[Ralf Corsepius <ralf dot corsepius at rtems dot org>]

On Sat, 2007-09-15 at 05:52 -0600, Eric Blake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> According to Ralf Corsepius on 9/14/2007 11:33 PM:
> > On Fri, 2007-09-14 at 10:41 -0500, Joel Sherrill wrote:
> >> Hi,
> >>
> >> I am porting a library to RTEMS that is calling clearenv().
> >> I am willing to implement one for newlib.
> > Frankly speaking, I am opposed to letting clearenv() into newlib,
> > because it is a non-standardized, non-documented function.
> 
> It is well documented, just not standardized yet; and it can be a whole
> lot more efficient than repeated unsetenv() calls, not to mention that
> without clearenv() you must walk environ, which POSIX discourages.  And I
> am not opposed to adding it at ELIX level 4.  If you use static linking,
> there is nothing wrong with additional functions in newlib, as long as
> they are in their own .o file, because they do not bloat your executable
> if you do not use them.  And in larger systems with shared libraries, such
> as cygwin, the extra functions make newlib more useful, and can still be
> filtered by using smaller ELIX levels.  For example, witness the recent
> addition of funopen and fopencookie to newlib - neither function is
> standardized (funopen comes from BSD and fopencookie from Linux), 

Right, these recent additions are cause me grief, because one lesson
RTEMS has learned from it having been generous on adopting
BSD-proprietary functions in the past, is:
 
Avoid adopting and supporting any proprietary non standardized APIs is
harmful.

The RTEMS steering committee (Which both Joel and I are members of) had
decided to follow POSIX and to avoid such functions. So far, the recent
newlib additions/extensions (which I am opposed to, as you probably
know.) don't affect us (yet), because we current stay with
newlib-1.15.0.

We haven't yet decided what to do with these additions/extensions for
RTEMS, but we're not unlikely to revert them for RTEMS.

Ralf