clearenv for newlib
Tue Sep 18 20:05:00 GMT 2007
On Mon, 2007-09-17 at 17:07 -0500, Joel Sherrill wrote:
> 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), but
> > having them at ELIX level 4 makes it easier to port autogen to Cygwin.
> I don't have a problem with adding BSD compatible methods
> that are written in modern C.
I do have a problem with OS implementors who claim to be aiming at
targetting small systems allow their libc (which is part of the OS)
allow their OS to gradually blow up by their
> I thought most of the problems
> we encountered with BSD routines in RTEMS were header
> file and type conflicts.
Right, conflicts between BSD implementation and other standards are one
part of the problem. Another part is "proprietary standards" often
lacking generality and portability.
clearenv seems to such a case.
The real problem however is elsewhere: OS implementors willing to extend
bloat their OS (comprising libc) due to application developers having
missed the non-portability of the foundations of their approach and them
relying "what they find on their primary devel platform."
It's the classical "GLIBC has X, Cygwin hasn't", "BSD has Y, RTEMS
hasn't" => newlib must implement. I consider this chain harmful.
> I do have a problem adding it when there are questions
> about how to implement it. And since I can't figure out
> how to reliably free the memory without adding tracking
> code, that makes me not want to add it.
Right, IMO, you've encountered a case of a non-standardized function
which isn't easily portable.
More information about the Newlib