[This doesn't belong in cvs-all and Nate has already made comments in -hackers]
On 2002-Nov-14 14:57:39 -0800, Matthew Dillon <[EMAIL PROTECTED]> wrote: > I think the real issue is the bloat in libc. printf() eats 20K, basic > stdio eats 5K. You get 15K of bloat just with a blank main(), a good > chunk of that being malloc() (reasonable in larger programs, ridiculous > in tiny programs where you don't care about malloc() efficiency). As a (partial) counter-argument: For long-running processes that make extensive use of malloc (eg /bin/sh), malloc() 'efficiency' does matter. Likewise, in an embedded environment, the 15KB of text space you save may be more than offset by a malloc implementation that is less frugal in heap space. > Why not create a mini-libc? No language-aware character conversions, > no efficient string or memory functions, no floating point. Just a basic > implementation of the core functionality required for stdio, malloc, > *printf(), string functions, and system calls (which will simply be > borrowed from libc), sufficient for simple binaries. It could be made > compatible with our standard includes (structural bloat != code bloat, > so who cares). I think Nate's got a good point regarding maintainability here. If we do want to create a mini-libc, we need to minimise the amount of code duplication. Note that, based on a quick nm and size on libc.a, we could halve the size of printf() by undefining 'FLOATING_POINT' in vfprintf.c, with virtually no additional maintainability effort. (Xenix/286 used to have both integer-only and FP-aware variants of the standard libraries. The compiler would automatically select the libraries based on FP references in the code. Though I do recall managing to confuse it on one occasion). Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
