[uClibc]Re: malloc-930716/malloc.c

Erik Andersen andersen at codepoet.org
Thu Sep 5 06:29:25 UTC 2002


On Thu Sep 05, 2002 at 02:50:03PM +0900, Miles Bader wrote:
> Erik Andersen <andersen at codepoet.org> writes:
> > > Is there a reason for putting all the various malloc functions for
> > > malloc-930716 into a single file (malloc.c) -- even though they _used_
> > > to be in separate files?
> > 
> > The main reason was that 1) all the static only folks use
> > "malloc" and 2) for the shared library case, having them all 
> > in a single file is smaller and avoids namespace pollution.
> 
> It's not _necessarily_ the case that it's better for shared libraries
> though.  One case in which they also benefit from small object files is

Yeah. I just split out memalign and realloc.  malloc and free are
still in a single .o, but I expect most people will be using
those two together.  Granted for the trivial case, one could let
the kernel cleanup in _exit()....

> when you're using a library tree-shaker to shrink the shared libs down
> for a very small system.
> 
> [Incidentally, is anyone planning on doing this (making a tree-shaker)?
> It's not very hard.  I wrote one of these once when trying to make hurd
> boot floppies, and it made glibc a _lot_ smaller...  :-) ]

Like uClibc/extra/libstrip/libstrip?  For something more
comprehensive, mklibs.py (from Debian) works just great....

> As for name pollution, isn't this fairly simple to work around?
> Besides just using `__' prefixes for everything, I was under the
> impression that glibc used various wierd and exotic techniques to get
> even less pollution from internal symbols...

Yeah.  Using _ prefixes is legal.  The namespace is still
polluted.  Regardless, its done.  5 more _ prefixed symbols.

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--



More information about the uClibc mailing list