Russell Nelson <[EMAIL PROTECTED]> writes:
> The problem is that the portability hacks have the wrong attitude. They
> say "how do we get program foo to work with os bar's c library"? Dan
> says "os bar's c library is a piece of shit anyway. Why bother figuring
> out all the many and myriad ways it's been munged? Here's a decent
> library, and we'll figure how what's different about the syscalls."
> Basically, if you program to Dan's C library, you don't *have* any
> portability problems. Well, actually, once you get out of the problem
> domain that Dan's already solved, you might need to solve a few more
> problems.
You're viewing portability in the small view, I think, rather than the
large view. Portability isn't just about portability to different
systems. It's also about portability to different applications and
environments, and it's about taking advantage of the native benefits of
each application as much as you can without sacrificing generality.
Dan uses his own C library, which means that he misses all of the
optimization that a given vendor may put into libc. He misses transparent
support for some service that platform may want to use. He misses
reasonable block sizes for the particular platform (Dan uses very small
buffers).
In the specific domain in which he's writing, namely a very high-security
program that needs a maximum amount of reliability, this makes sense.
Most programs are not security programs; programs which never run with
privileges other than those of the user who invoked them aren't nearly as
sensitive to such things. A buffer overflow in such a program is
generally only a bug, not a total disaster, for example. *In that
environment*, the kind of portability you get from rewriting everything
yourself is false portability. You do more work to maintain your own libc
and you lose everyone else's work.
Note that I haven't seen Dan advocating the sort of generalizing of his
personal coding techniques that you are. He's applying those techniques
to a specific domain where they make sense. I'm advocating not just
copying them blindly to other domains, and not discounting other ways of
solving those problems.
Also note that Dan is reinventing parts of autoconf in his build process;
that's what all those try programs are. He's doing precisely the same
thing that autoconf does, namely write out a little program, compile it,
and see what happens. So he's actually using precisely those "child's
babblings" that you're dismissing, and using them in a similar way; he
just hasn't surrounded them with m4 macros.
--
Russ Allbery ([EMAIL PROTECTED]) <URL:http://www.eyrie.org/~eagle/>
