the one and only objection to C

[Henry Spencer]

> Suppose you're trying to read a file which starts with a 16-bit field,
> followed by a 32-bit field, then another 16-bit field.  Or suppose
> you're trying to handle an archive file, which has a 14-char array
> followed by an int of some sort.  The turkey compiler on your 32-bit
> machine insists on aligning things "properly" on 4-byte boundaries.
> (This would be fine if it would also transform all the files involved,
> but it isn't that smart!)
> 
> So what do you do?  You dig in to the code, changing the 32-bit fields
> to pairs of 16-bit fields.  Then, wherever the fields were mentioned,
> you modify the code to extract the two little fields and combine them.

Actually, the preferred approach is to simply read the fields one at a
time instead of being lazy and trying to read the whole structure in one
gulp.  This would seem much simpler.  It also will become necessary
the instant you hit byte-ordering or word-ordering problems.  I hope you
don't think the compiler should "solve" them, too.

> It would be much nicer if C compilers would accept the fact that some
> fields are misaligned and generate the code to handle it.  This would
> save me a lot of work, and isn't that why high-level languages exist?

You might (repeat, might) be able to accomplish this with bitfields.
If your compiler is feeling cooperative that day...  Of course the
bitfield declarations will be machine-dependent.  You can't win.
-- 
"Face Mecca and repeat three times:  'binary file formats are not portable'".

				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry