What about the pathological case of an install floppy, where you've
got space constraints?
>Oh well, I know that Unix is the reign of text and strings, so I'm not going
>to change that in this list. Go ahead with your strings everywhere and we'll
>just keep on parsing/unparsing/parsing/unparsing/...
Is this a critical path where the extra cycles are blocking
functionality? If not, why bother changing the parsing scheme from
parsing text to parsing arbitrary binaries? It's as easy, if not
easier, to write tools that will take as input well-behaved text (if a
human does not generate this text, this is almost a given) and produce
arbitrary output as it is to write tools that take as input
well-behaved binary data and produce arbitrary output. Plus you get
the benefits of a human-readable interface without carrying around a
lot of external tools, at the cost of locking yourself into a
language (which, compared to the cost of locking yourself into
binary data blocks doesn't seem quite so horrible) and a bit of
stringspace in the kernel.
(Of course this only applies when both the interface and the tools
that read it are well-behaved. Arp -a is a notable case of this; when
I was forced to upgrade my server to 2.0.28, arp -a just stopped
working, despite reading /proc/net/arp for the arp list.)
____
david parsons \bi/ orc@pell.chi.il.us
\/