[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