type and size of bit-fields

[Steven Sargent]

brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:

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

---
We've moved from general rules about writing binary files
to your particular application (and even further from topics
in the C language!).  So I'll try not to overdo.

In your application, do what you want.  You're providing
a tool for wheels (/etc/shuctld); system administration
stuff often cuts corners on portability, so you'll not be
much worse than other providers.  (You doubtless will run
into somebody who wants to build shu.cc files at one machine,
and then distribute them automagically to heterogenous
machines; but that's *his* problem, not yours, right?)  Much
better, you provide shu.cc as an efficiency hack to shu.conf,
so that it can be regenerated more or less painlessly.

For applications whose charter is to be portable across
heterogeneous systems, binary files are rather messier.
Probably the worst thing to do is to drop in arbitrary unpadded
struct/unions, pointers, floating point numbers, and similar
trash.  Write transfer functions between file- and VM-resident
versions of the structures, and you've solved most of the
problem, given that you do something sensible with byte/word
ordering.  Provide a schema for the file, either explicitly,
or implicitly via the file's version string.

Users can and do "invariably trash" binary files as well as
text files, by using them via soft NFS mounts, or sending them
around over 7-bit communication paths, or mistakenly opening
and saving them with vi; a little paranoia on the application's
part doesn't hurt.  Write a header including a magic number
and version string.  If you're really nervous, think about
writing checksums.

Using these hints, you're still getting most of the speed
benefit of binary files (generally, but not always, more
compact than the ASCII version; no text strings to decode),
and a better chance of portability.  Your code will be more
complex, but you know better than I do where that trades off
for you.

-- 
Steven Sargent sbs at frame.com	"Frame's phone bill, my opinions."