Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!caen!news.cs.indiana.edu!nstn.ns.ca!uupsi!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.c
Subject: Re: type and size of bit-fields
Message-ID: <13348:Mar2116:17:0691@kramden.acf.nyu.edu>
Date: 21 Mar 91 16:17:06 GMT
References: <1991Mar20.224317.1265@grebyn.com> <1991Mar21.021023.25615@athena.mit.edu>
Organization: IR
Lines: 26

In article <1991Mar21.021023.25615@athena.mit.edu> scs@adam.mit.edu writes:
> The moral: DON'T USE BINARY DATA FILES.

Binary files often increase not only efficiency, but security and
reliability. What am I referring to? Compilations.

There are examples of this other than language compilations. I'm working
on a system program, shuctld, which takes a readable configuration file,
typically /etc/shu.conf, compiles it into /etc/shu.cc, and then uses
/etc/shu.cc. This saves up to a few seconds of parsing and service-host
lookup time at the beginning of every network connection.

Not only that, but if someone makes a syntax error in /etc/shu.conf,
shuctld will blare a few warnings in various places and continue using
the old /etc/shu.cc. You know what happens if you mess up /vmunix and
then reboot? That can't happen with /etc/shu.conf.

shuctld automatically checks whether /etc/shu.cc is newer than
/etc/shu.conf, so you don't have to worry about the files getting out of
sync. It can also check /etc/shu.cc against its own executable, so that
you don't even have to worry if the compiled format changes.

Now why shouldn't shuctld use an easy-to-parse, reliable binary file,
rather than a text file that users will invariably trash?

---Dan