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

Miles Bader miles at lsi.nec.co.jp
Thu Sep 5 05:50:03 UTC 2002


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
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...  :-) ]

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...

> In the case of memalign (which is almost never used) it probably
> makes more sense to split that out into a separate file.  It
> might be feasible to split out realloc, at the cost of some minor
> namespace pollution.

I'm not entirely confident, but I think realloc is not used all _that_
often either (unless maybe it's used by stdio or something).

> But malloc and free are are pretty intimately connected and there
> would be little benefit from splitting them.

Yeah... though I'm sure there are programs out there that call malloc
and never call free...

-Miles
-- 
`The suburb is an obsolete and contradictory form of human settlement'



More information about the uClibc mailing list