:> 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
What I did in DICE was put a full FP-supporting printf core
in libm, and an integer-only printf core in libc. If you
added -lm to the link line you got the full printf, otherwise
you got the integer-only printf.
I don't think that's workable for FreeBSD, though, people just
expect FP in printf without libm these days, so it would still
make sense to create a mini-libc. It's unfortunate, but libc
has turned into a kitchen sink for just about everything.
I would not worry too much about duplicate code. It just isn't
a big issue. The whole idea of having a mini-libc is that it
would contain only a subset of features, as unfancy as possible.
This translates to very few bugs and virtually no additional
maintainance burden.
In regards to integrating a mini-libc with libstand... well,
that would be possible but to do it right would require
a radically different approach. In DICE I had a 'librom'
which was platform independant code (made no system calls,
just pure infrastructure functions like pfmt(), s*printf(),
strcpy(), etc...). I would approach a mini-libc and libstand
integration by creating a 'librom' equivalent, and then
having libstand extend it out and mini-libc (as a separate
entity) also extend it out. That would reduce code duplication
considerably yet still allow the libraries to focus on the
particular functions they were designed for.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
